암호·오류·로깅·캡슐화·API 보안

핵심 요약

암호 기술은 기밀성·무결성·인증 등 보호 목적으로 구분한다. 오류와 로그는 내부 정보를 과도하게 노출하지 않으면서 문제 추적에 필요한 내용을 남겨야 한다. 캡슐화와 안전한 API 사용은 내부 상태와 권한이 외부 입력 때문에 무너지지 않도록 하는 설계·구현 원칙이다.

1. 암호·해시·서명의 목적

암호화 전 데이터는 평문, 암호화한 결과는 암호문, 암호문을 평문으로 되돌리는 과정은 복호화다. 해시는 정상적인 복호화로 원문을 되찾는 암호 방식이 아니다. 인코딩은 표현 변환이고 암호화와 목적이 다르다.

수신자의 공개키로 암호화하면 대응 개인키를 가진 수신자의 복호화를 기대할 수 있지만, 그 사실만으로 발신자의 신원이 증명되지는 않는다. 서명은 서명자의 개인키와 연결되지만 메시지 기밀성을 자동 제공하지 않는다.

좌우로 이동해 그림을 확인하세요.그림 크게 보기

2. 대표 암호 알고리즘

‘AES-256의 블록 크기는 256비트’는 틀리다. 숫자 256은 키 길이이며 블록은 128비트다. Diffie-Hellman은 그 자체를 대용량 본문을 암호화하는 블록 암호로 분류하지 않는다.

MD5·SHA-1·SHA-2·SHA-3는 해시 알고리즘 계열이다. MD5는 128비트, SHA-1은 160비트 요약값을 생성하고 SHA-256은 256비트 요약값을 생성한다. DES·3DES 및 MD5·SHA-1 등 구형 알고리즘의 시험상 식별과 신규 보안 설계의 안전한 선택은 구분해야 한다. 취약하거나 사용이 제한되는 구형 기술을 현재의 안전한 기본 선택처럼 취급하지 않는다.

블록 암호를 사용했다는 사실만으로 모든 위협을 막는 것은 아니다. 적절한 운영 모드, 키·초기화 값 관리, 무결성 확인이 필요하다. 인증 암호화는 기밀성과 변조 검출을 함께 제공하도록 설계된 방식이다.

3. 비밀번호와 키 관리

비밀번호는 단순한 평문 저장이나 복호화 가능한 암호화에 의존하기보다 검증 목적에 맞는 비밀번호 전용 해시와 사용자별 salt를 사용한다. salt는 같은 비밀번호의 결과를 다르게 하고 사전 계산 공격의 효율을 낮춘다. salt 자체는 일반적으로 비밀키가 아니다.

빠른 일반 해시를 한 번 적용하는 것과 의도적으로 비용을 조절하는 비밀번호 해시는 다르다. 암호키는 소스·공개 설정·로그에 하드코딩하지 않고 접근권한을 제한하여 관리한다. 보안용 난수는 예측 가능한 일반 난수·현재 시각만으로 대신하지 않는다.

키는 생성·배포·저장·사용·교체·폐기의 수명주기로 관리한다. 키가 유출되면 교체뿐 아니라 해당 키로 보호한 데이터와 계정의 영향을 검토해야 한다. 키 교체가 이미 유출된 평문을 회수하는 것은 아니다.

4. 안전한 오류 처리

오류 처리에는 정상적인 실패 전달, 자원 정리, 일관된 상태 복구가 포함된다. 오류를 숨기기 위해 예외를 무시하면 일부 갱신만 반영되거나 자원이 누수될 수 있다.

스택 추적, SQL 전체, 내부 경로, 계정·키 등을 사용자 응답에 그대로 노출하면 공격에 필요한 정보를 제공할 수 있다. 반면 모든 정보를 버리면 문제 분석이 어려워진다. 외부 최소 오류와 내부 진단의 분리가 핵심이다.

5. 보안 로그

로그에는 사건의 시각, 행위 주체, 대상, 수행 작업, 성공·실패 결과 등 분석에 필요한 정보를 남긴다. 인증 실패, 권한 변경, 중요 데이터 접근과 같은 사건을 구분할 수 있어야 한다.

비밀번호·세션 토큰·API 키·개인키를 로그에 기록하지 않는다. 민감정보를 남겨야 하는 경우에도 목적에 필요한 최소 범위와 접근권한·보존 조건을 적용한다.

외부 입력의 줄바꿈·제어문자로 가짜 로그가 끼어드는 로그 삽입도 주의한다. 구조화된 기록과 필드 길이·제어문자 처리 등을 사용하고, 로그 파일의 무단 수정·삭제를 제한한다. 로그가 있다는 것만으로 누락·변조가 없거나 행위가 법적으로 확정되는 것은 아니다.

6. 캡슐화와 내부 상태 보호

캡슐화는 데이터와 행위를 묶고 정해진 인터페이스로 상태를 보호하는 원칙이다. 접근 제한자를 private로 선언하는 것만으로 충분하지 않을 수 있다.

내부의 가변 배열·목록을 public 메서드가 그대로 반환하면 외부 코드가 같은 객체를 수정하여 내부 상태를 바꿀 수 있다. 반대로 외부에서 받은 가변 객체를 내부 필드에 그대로 저장해도 외부 변경의 영향을 받을 수 있다. 방어적 복사·불변 자료구조·변경 가능한 인터페이스의 제한을 적용한다.

전역·공유 객체에 사용자별 민감 상태를 저장하면 서로 다른 세션 사이에 데이터가 섞일 수 있다. 제거하지 않은 디버그 기능, 직렬화·문자열 출력에서 노출되는 내부 필드도 점검한다.

7. API 오용과 API 보안

API를 사용할 때는 입력 조건, 반환값, 오류, 자원 소유권, 보안 기능과 부작용을 이해해야 한다. ‘제공된 라이브러리이므로 아무렇게나 호출해도 안전하다’는 전제는 잘못되었다.

웹 API에는 인증뿐 아니라 기능·객체·속성별 인가가 필요하다. 호출 횟수와 자원 사용량도 제한하여 정상 형식의 대량 요청에 의한 서비스 고갈을 줄인다.

OWASP Top 10과 OWASP API Security Top 10은 각각 일반 웹 애플리케이션과 API의 대표 위험을 다루는 별도 목록이다. 모든 취약점을 포괄하는 완전한 시험 목록이나 특정 제품의 인증서는 아니다. 서로 다른 목록의 버전·번호를 혼합 암기하지 않는다.

암호의 목적·키 수명과 안전한 API 처리

DES의 64비트 키 표현 중 8비트 패리티는 유효 키 길이에 포함하지 않는다.

SHA-256의 출력은 256비트=32바이트다. 16진수 한 문자는 4비트를 나타내므로 해시를 16진수로 표현하면 64문자가 된다. Base64·16진수는 표현 방식으로, 그 자체가 암호화나 인증을 제공하지 않는다.

AEAD는 기밀성과 인증을 함께 제공하는 암호 방식이다. 인증 태그 검증에 실패한 메시지는 유효한 업무 데이터로 사용하지 않는다. AES-GCM에서는 같은 키 아래 nonce(IV)를 재사용하지 않는 것이 중요하다. nonce가 공개될 수 있다는 것과 중복 사용이 안전하다는 것은 다르다. 구체적인 알고리즘·운영 모드에 맞는 요구를 적용한다.

비밀번호 저장에 사용자별 salt를 쓰면 같은 비밀번호의 저장값을 단순 비교하거나 사전 계산 결과를 광범위하게 재사용하기 어렵게 한다. salt는 보통 비밀 키가 아니며 복호화 기능이 없다. 느린 비밀번호 전용 해시와 적절한 매개변수, 온라인 시도 통제도 필요하다. salt가 충돌 가능성을 수학적으로 없애거나 약한 비밀번호를 무조건 강하게 만드는 것은 아니다.

키를 교체해도 과거 암호문은 자동 변환되지 않는다. 암호문과 키 버전의 대응, 재암호화, 통제된 이전 키 보존과 안전한 폐기 시점을 계획한다. 읽어야 하는 자료의 유일한 복호화 키를 계획 없이 폐기하지 않는다.

오류 처리에서는 민감한 정보의 노출뿐 아니라 부분 처리 상태도 확인한다. 하나의 트랜잭션인 이체에서 출금 후 입금이 실패하면 롤백 등으로 원자성을 지켜야 한다. 오류 메시지를 숨기거나 로그만 남긴다고 데이터가 복구되지는 않는다.

API가 요청 필드를 객체에 무제한 자동 바인딩하면 사용자가 권한·소유자 같은 민감한 속성을 바꿀 수 있다. 이를 Mass Assignment 관점에서 점검하고 수정 가능한 필드의 허용 목록을 적용한다. 역방향 DNS의 호스트 이름도 접속 주체의 신원 증명과 인가를 대신하지 않는다. 키·토큰·비밀번호·전체 민감 정보는 불필요하게 로그로 남기지 않는다.