사용자가 문서 번호 42를 요청했습니다. 요청 형식이 맞고 로그인도 했으니 문서를 반환해도 될까요? 그 문서가 다른 조직의 비공개 자료라면 안 됩니다. 보안은 특정 암호화 알고리즘을 붙이는 것보다 먼저, 무엇을 누구에게 어떤 조건으로 허용할지 정하는 문제입니다.
보안 검토는 요청 문자열을 안전하게 만드는 일에서 시작하지 않고, 요청이 접근하려는 자산과 권위 있는 주체를 확정하는 일에서 시작합니다. 문서 42 사례에서는 형식 검증, 인증 문맥 추출, 서버에서 대상 문서 조회, 행동별 인가, 허용 필드 반환의 순서를 분리합니다. 한 단계의 성공을 다음 단계의 성공으로 재사용하지 않는 것이 이 노트의 기본 진입 규칙입니다.
자산과 신뢰 경계
보호할 대상은 비밀번호만이 아닙니다. 비공개 문서의 내용, 주문의 정확한 금액, 정상 사용자가 서비스를 사용할 수 있는 용량도 자산입니다. 각각 기밀성, 무결성, 가용성과 연결됩니다.
브라우저에서 서버로 넘어오는 값은 사용자가 바꿀 수 있습니다. 서버가 외부 API에서 받은 응답도 그 API의 신뢰 범위 안에서만 해석해야 합니다. 데이터가 다른 주체의 통제 영역으로 넘어오는 지점을 신뢰 경계라고 합니다. 경계에서는 누가 만든 정보인지와 무엇의 근거로 쓸 수 있는지를 따져야 합니다.
인증과 인가
인증은 요청 주체가 누구인지 확인하는 과정입니다. 인가는 그 주체가 특정 대상에 특정 행동을 할 수 있는지 판단하는 과정입니다. 로그인 성공은 인증의 결과이지 모든 문서의 읽기 허가가 아닙니다.
서버는 세션이나 검증된 토큰에서 사용자 A를 얻고, 문서 42의 소유 조직과 공개 정책을 조회합니다. 요청에 userId=B를 넣었다고 B로 인정하지 않습니다. A가 문서를 읽을 권한이 있어도 삭제 권한은 없을 수 있으므로 행동까지 함께 검사합니다.
그림을 글로 읽기
- 요청 · 문서 42 읽기
- 인증 · 검증된 사용자 A
- 인가 · A의 문서 42 읽기 권한
- 허용된 필드만 반환
- 요청 · 문서 42 읽기 → 인증 · 검증된 사용자 A: 신원 확인
- 인증 · 검증된 사용자 A → 인가 · A의 문서 42 읽기 권한: 주체·행동·대상
- 인가 · A의 문서 42 읽기 권한 → 허용된 필드만 반환: 허용 결과
실패를 진단할 때는 파싱 오류, 인증 실패, 대상 부재, 인가 거절, 출력 문맥 오류를 서로 다른 관찰값으로 남깁니다. 문서 번호가 정수라는 로그만으로 접근 허용을 설명하지 않고, 서버가 조회한 소유 조직과 행동별 정책 결정까지 연결해야 실제 권한 우회 여부를 판별할 수 있습니다.
형식 검증과 의미 검증
문서 번호가 정수인지 검사하면 잘못된 형식을 줄일 수 있습니다. 하지만 그 번호가 실제 존재하는지, 사용자에게 공개 가능한지까지 알 수는 없습니다. JSON이 올바르게 파싱됐다는 사실도 내용이 안전하다는 뜻은 아닙니다.
SQL에서는 입력값을 SQL 문법과 분리해 바인딩합니다. HTML에서는 출력 위치에 맞게 인코딩합니다. URL을 대신 방문하는 기능은 목적지를 검사합니다. 모두 문자열을 받지만 그 문자열이 해석되는 문맥이 다르므로 하나의 ‘위험 문자 제거’ 함수로 대체할 수 없습니다.
암호화·해시·서명
| 수단 | 기본 목적 | 남는 판단 |
|---|---|---|
| 암호화 | 키 없이 내용을 읽기 어렵게 함 | 누가 복호화 키를 갖는지 |
| 해시 | 입력에서 고정 길이 검증값 계산 | 기대 해시를 어디서 신뢰했는지 |
| 서명·MAC | 키에 근거한 변조 검출과 인증 | 키의 신뢰·용도·재생·만료 |
서명된 토큰도 만료되었거나 다른 서버용이면 거절해야 합니다. 파일과 해시를 공격자가 함께 바꿀 수 있다면 해시 일치만으로 안전한 출처를 증명하지 못합니다. TLS는 연결의 보호와 상대 인증에 도움되지만 앱의 문서 소유권 검사를 대신하지 않습니다.
최소 권한과 자격 수명
읽기 전용 기능에 관리자 자격을 주면 한 번의 실수가 큰 변경으로 이어집니다. 필요한 대상·행동·기간으로 권한을 좁히는 것이 최소 권한입니다. 앱이 가진 서비스 계정 권한과 최종 사용자가 허용한 행동도 구분해야 합니다.
권한은 발급 뒤에도 바뀝니다. 사용자가 조직을 떠났는데 오래된 토큰이나 캐시가 계속 허용하면 철회가 늦어집니다. 검사와 실제 쓰기 사이에도 권한이 바뀔 수 있어 민감한 변경에는 현재 정책과 쓰기의 순서를 맞추는 설계가 필요합니다.
세부 학습 경로
자원별 인가 → 로그인 거래 → 세션과 회수로 이어집니다. 입력 경계는 데이터 파싱, 브라우저 보안, 서버 URL 조회에서 구체화합니다.