보안 기능이 있다는 설명과 그 기능을 믿을 근거는 다르다

기능 목록은 시스템이 무엇을 해야 한다고 설계했는지 말합니다. 그 기능이 요구된 상황에서 구현되어 작동한다는 확신은 설계 추적, 검토, 시험 결과와 적용 범위 같은 별도의 근거로 세워야 합니다.

시험에 통과한 입력과 환경을 넘어 모든 우회가 없다고 단정할 수는 없습니다. 주장의 범위, 근거가 다루는 구성요소, 남은 가정을 함께 적어야 합니다.

기능 설명은 보안 보증서가 아닙니다

가상의 문서 서비스 요구사항에 ‘사용자는 자신에게 허가된 파일만 읽는다’고 적혀 있다고 해 보겠습니다. 이 문장은 필요한 기능을 말합니다. 개발자가 화면에 권한 버튼을 만들었다거나 기능 목록에 접근통제를 적었다는 사실만으로 모든 읽기 경로에서 정책이 적용된다는 결론은 나오지 않습니다. 배경 작업, 파일 미리보기, 백업 복원, 관리자 도구가 다른 경로로 파일을 열 수 있기 때문입니다. 기능 요구는 무엇을 해야 하는지 정하고, 보증 근거는 그 요구가 설계와 구현에서 어떻게 충족됐는지 판단할 자료를 제공합니다.

주장을 근거에 연결하는 순서

1. 먼저 주장을 관찰 가능한 문장으로 좁힙니다. ‘안전하다’ 대신 ‘사용자 A의 권한이 없는 파일을 본문 API가 반환하지 않는다’고 적습니다.
2. 주장이 적용되는 사용자, API, 파일 종류, 배포 구성과 예외를 나열합니다.
3. 요구사항이 설계 요소와 구현 단위로 이어지는 추적을 확인하고, 빠진 경로가 있는지 찾습니다.
4. 예상 허용과 거부 결과를 미리 적은 시험을 확인합니다. 통과율뿐 아니라 실행한 버전·환경·입력 범위를 기록합니다.
5. 남은 가정과 관찰하지 않은 영역을 별도로 씁니다. 예를 들어 관리자가 수동으로 권한을 바꾸는 절차는 시험 범위 밖일 수 있습니다.

예를 들어 시험표에 ‘권한 없음, GET /files/7, 응답 403’ 한 건이 있다고 합시다. 이 결과는 그 입력과 그 버전에서 거부 응답이 나왔다는 증거입니다. 같은 파일을 내려받는 별도 경로, 이미 열린 세션의 권한 변경, 캐시된 미리보기까지 검사했다는 뜻은 아닙니다. 이때 적절한 문장은 ‘해당 시험 조건에서 본문 API가 요청을 거부했다’입니다. ‘서비스 전체에 우회가 없다’는 문장은 근거가 지지하는 범위를 넘어섭니다.

증거의 양보다 주장과의 연결을 봅니다

설계 문서가 두껍거나 시험 건수가 많아도 근거가 핵심 주장과 맞지 않으면 보증이 약합니다. 화면 버튼이 권한을 숨긴다는 테스트는 서버가 직접 요청을 거절하는지 답하지 못합니다. 반대로 작은 시험이라도 명확한 가정과 함께 특정 실패 경로를 재현하면 그 좁은 주장을 뒷받침할 수 있습니다. NIST SP 800-160 Vol. 1 Rev. 1은 보안을 시스템 생애주기에서 공학적으로 다루는 지침이며, NIST SP 800-53A Rev. 5는 통제 평가 절차와 결과 분석을 제공합니다. 두 문서는 실제 제품의 인증서나 무결점 증명으로 바꾸어 읽지 않습니다.

회상 연습: 주장에 맞는 근거를 고릅니다

교육용 문제입니다. 가상 서비스의 권한 거부 API에 대해 코드리뷰와 ‘사용자 A가 파일 7을 요청했을 때 403을 받았다’는 시험 기록이 있습니다. 이 근거로 가장 정확히 말할 수 있는 결론은 무엇이며, 주장 범위를 넓히려면 무엇을 더 확인해야 하나요?

정답은 ‘검토한 코드와 실행 조건에서 해당 요청이 거부됐다’입니다. 모든 파일 API가 같은 정책을 적용하는지, 다른 역할·예외·캐시·배포 구성이 있는지 추적하고 추가 시험해야 합니다. 시험 결과는 조건이 붙은 증거입니다. 요구사항이나 기능 이름만으로 작동의 보증을 대신할 수 없습니다.