보안 감사
더 많은 작업
- Security Audit; 보안 감사, IT 감사
- 조직의 보안 통제가 정책·표준·법규 요구사항에 맞게 설계되고 운영되는지를 독립적인 입장에서 기록과 활동을 검토해 확인하고, 그 결과를 이해관계자에게 보증(assurance)하는 활동
NIST 용어집은 보안 감사를 "시스템 통제의 적정성을 평가하고, 수립된 정책과 운영 절차의 준수를 확인하며, 통제·정책·절차에 필요한 변경을 권고하기 위해 기록과 활동을 독립적으로 검토하고 조사하는 것"으로 정의한다. 핵심어는 독립성과 기준 대비 판단이다. 취약점 스캔이나 모의 침투가 "실제로 뚫리는가"를 기술적으로 보는 데 비해, 감사는 "정해진 기준을 지키고 있는가, 그 증거가 있는가"를 묻는다.
감사 결과는 경영진과 이사회(감사위원회), 규제 기관, 고객과 같은 외부 이해관계자가 조직의 보안 상태를 믿고 의사결정을 하는 근거가 된다. 그래서 감사는 보안 담당 부서가 스스로 하는 점검과 달리 수행자의 독립성, 증거의 충분성, 보고 대상이 엄격하게 따져진다. CISSP 도메인 6(보안 평가 및 테스트)의 6.1(평가·테스트·감사 전략 설계)과 6.5(보안 감사 수행·지원)가 이 주제를 다룬다.
- 보안 통제가 의도대로 설계되었고(설계 적정성) 실제로 작동하는지(운영 효과성) 확인한다.
- 법규·계약·인증 기준(ISO/IEC 27001, PCI DSS, ISMS-P 등) 준수 여부를 판단한다. 자세한 내용은 컴플라이언스 문서를 본다.
- 경영진에게 통제 미비점과 그 위험을 알려 개선을 이끈다. 감사는 문제를 고치는 활동이 아니라 문제를 드러내고 책임자에게 조치를 요구하는 활동이다.
- 고객·규제 기관 등 제3자에게 신뢰를 제공한다. 서비스 조직이 고객에게 제공하는 SOC 보고서가 대표적이다.
CISSP 시험 개요(2024)는 감사 주체를 조직과 기업의 통제 범위로 구분한다. 일반 회계·감사 용어의 "1자·2자·3자 감사"와 표현이 조금 다르므로 개요의 정의를 기준으로 기억한다.
| 유형 | CISSP 개요의 정의 | 수행 주체 예 | 주요 용도 | 독립성 |
|---|---|---|---|---|
| 내부 감사(internal audit) | 조직이 통제하는 범위 안(within organization control) | 회사 내부감사부서, 정보보호 관리체계 내부 점검반 | 자체 개선, 외부 감사 대비, 경영진 보고 | 감사 대상 부서와 분리되어야 하며, 보고선은 감사위원회나 최고경영자로 둔다 |
| 외부 감사(external audit) | 조직 통제 밖(outside organization control) | 고객사·모회사가 공급업체를 감사, 계약에 따른 감사권 행사 | 계약 이행 확인, 공급망 위험 평가 | 감사받는 조직과 이해관계가 다른 주체가 수행 |
| 제3자 감사(third-party audit) | 기업 통제 밖(outside of enterprise control) | 인증 심사 기관, 공인회계법인, 규제 기관 | 인증 취득, 법정 감사, 공개 보증 보고서 | 가장 높다. 결과를 여러 이해관계자가 신뢰할 수 있다 |
- 독립성은 내부 < 외부 < 제3자 순으로 높아지고, 비용과 준비 부담도 같은 순서로 커진다.
- 내부 감사는 외부 감사의 대체물이 아니라 준비 단계이자 상시 점검 수단이다. 국내 ISMS-P 인증기준 1.4.2(관리체계 점검)도 독립성과 전문성을 갖춘 인력으로 연 1회 이상 점검하고 결과를 경영진에게 보고하도록 요구한다.
| 위치 | 감사 접근 방식 | 주의할 점 |
|---|---|---|
| 온프레미스 | 감사인이 시설·장비·로그·설정에 직접 접근해 증거를 수집한다 | 물리적 접근, 증거 보존 절차, 운영 영향 최소화 |
| 클라우드 | 고객은 공급자의 데이터 센터나 하이퍼바이저를 직접 감사하기 어렵다. 공급자가 제공하는 제3자 보증 보고서(SOC 보고서, ISO 인증서, CSAP 등)와 고객 영역의 설정·로그를 결합해 판단한다 | 계약상 감사권(right to audit)이 제한적이다. 책임 분담(클라우드 서비스 모델별 공동 책임)에 따라 감사 범위를 나눈다. 보고서의 범위와 기간이 내 서비스·내 리전을 포함하는지 확인한다 |
| 하이브리드 | 두 방식을 함께 쓴다 | 온프레미스와 클라우드 사이 연동 지점(ID 연합, 네트워크 연결, 데이터 이전)이 감사 공백이 되기 쉽다 |
클라우드 감사에서 흔한 실수는 공급자의 보증 보고서를 받은 것만으로 "감사 완료"로 보는 것이다. 보고서에는 보완 이용자 통제(CUEC, Complementary User Entity Controls), 즉 고객이 직접 운영해야 효과가 있는 통제가 적혀 있다. 이 통제를 고객이 실제로 하고 있는지는 고객 자신이 감사해야 한다.
ISO 19011 계열 지침과 ISACA의 IT 감사 프레임워크(ITAF)는 감사를 계획 → 수행 → 보고로 나누어 설명한다. 실무에서는 보통 다음 다섯 단계로 정리한다.
| 단계 | 주요 활동 | 산출물 |
|---|---|---|
| 1. 계획(planning) | 감사 목적·범위·기준 확정, 위험 평가로 중점 영역 선정, 감사인 독립성 확인, 일정·자원 배정 | 감사 계획서, 체크리스트 |
| 2. 증거 수집(fieldwork) | 문서 검토, 담당자 면담, 관찰, 재수행(reperformance), 시스템 설정·로그 추출, 표본 추출(sampling) | 작업 조서(working papers), 증거 목록 |
| 3. 분석(evaluation) | 기준과 증거를 대조해 발견 사항(finding) 도출, 원인·영향·위험도 평가 | 발견 사항 초안 |
| 4. 보고(reporting) | 피감사 조직과 사실 확인(exit meeting), 감사 의견과 권고 사항을 경영진·감사위원회에 보고 | 감사 보고서 |
| 5. 사후 관리(follow-up) | 조치 계획 접수, 이행 여부 확인, 미조치 항목의 위험 수용 여부를 경영진이 결정 | 조치 이행 점검 결과 |
증거의 신뢰도는 대체로 "감사인이 직접 확인한 것(재수행·관찰) > 시스템이 생성한 기록 > 외부에서 받은 문서 > 피감사 조직의 진술" 순서로 본다. 면담만으로 결론을 내리면 안 된다.
| 기준 | 발행 기관 | 내용 |
|---|---|---|
| ISO 19011 | ISO | 경영시스템 감사 지침. 감사 원칙, 감사 프로그램 관리, 감사 수행, 감사인 역량을 다룬다. 2026년 5월에 제4판(ISO 19011:2026)이 나왔다. ISO/IEC 27001 인증 심사와 내부 심사의 바탕이 된다 |
| ITAF (IT Audit Framework) | ISACA | IT 감사·보증 전문가의 표준과 지침. 감사인의 역할과 책임, 윤리, 독립성, 계획·수행·보고 방법을 정한다. 2026년 2월 제5판이 발표되었다 |
| SSAE 18 (AT-C 320 등) | 미국 공인회계사회(AICPA) | 미국 공인회계사의 증명(attestation) 업무 기준. 서비스 조직 통제 보고서인 SOC 1·SOC 2가 이 기준에 따른다 |
| ISAE 3402 | 국제감사인증기준위원회(IAASB) | 서비스 조직의 통제에 대한 국제 인증 업무 기준. SOC 1과 대응된다 |
| 구분 | 테스트(test) | 평가(assessment) | 감사(audit) |
|---|---|---|---|
| 질문 | 이 통제가 실제로 작동하는가 | 우리 보안 상태와 위험은 어떠한가 | 기준을 지키고 있는가, 증거가 있는가 |
| 기준 | 기술 사양, 기대 결과 | 위험 기준, 모범 사례 | 정책·표준·법규·인증 기준(사전에 정한 기준) |
| 수행자 | 운영·보안 담당자 또는 외부 전문가 | 내부 또는 외부 전문가 | 독립적인 감사인 |
| 예 | 취약점 스캔, 모의 침투 테스트, 합성 트랜잭션 | 위험 평가, 보안 통제 평가, 성숙도 평가 | 내부 감사, 인증 심사, SOC 보고서 업무 |
| 결과물 | 기술 결과와 조치 항목 | 위험 목록과 개선 권고 | 감사 의견, 부적합·발견 사항, 공식 보고서 |
감사인은 테스트 결과를 증거로 쓰기도 한다. 예를 들어 모의 침투 결과 보고서, 취약점 조치 이력, 보안 지표 추이는 통제가 운영되고 있다는 증거가 된다.
CISSP 6.1은 평가·테스트·감사를 따로따로 하지 말고 하나의 전략으로 설계하라고 요구한다. 전략은 다음 질문에 답해야 한다.
- 무엇을 보증하려는가: 경영진 보고, 인증 유지, 고객 요구, 규제 대응 중 무엇이 목적인지에 따라 수행 주체와 기준이 달라진다.
- 누가 하는가: 내부(자체 점검, 내부 감사), 외부(고객·모회사 감사), 제3자(인증 기관·회계법인)를 위험과 비용에 맞게 섞는다. 규제나 고객이 독립적 보증을 요구하는 영역은 제3자에 맡긴다.
- 어디를 하는가: 온프레미스, 클라우드, 하이브리드별로 직접 테스트할 영역과 공급자 보증 보고서로 대체할 영역을 나눈다. 클라우드 공급자의 모의 침투 테스트 허용 정책도 확인한다.
- 얼마나 자주 하는가: 핵심 통제는 지속적 보안 모니터링과 자동화된 점검으로 상시 확인하고, 감사는 연 단위로 수행하는 식으로 주기를 겹치지 않게 짠다.
- 결과를 어떻게 쓰는가: 발견 사항은 취약점 관리와 위험 관리 절차로 넘기고, 조치하지 않는 항목은 위험 수용 승인을 받는다.
| 활동 | 주기 예 | 주 수행자 | 보증 수준 |
|---|---|---|---|
| 자동화된 구성 점검·취약점 스캔 | 상시~월 단위 | 운영·보안팀 | 낮음(자체 확인) |
| 모의 침투 테스트, 침해 공격 시뮬레이션 | 분기~연 단위, 큰 변경 후 | 내부 레드팀 또는 외부 전문 업체 | 중간 |
| 내부 감사 | 연 1회 이상 | 내부감사부서 | 중간 |
| 제3자 감사·인증 심사 | 인증 주기에 따름 | 인증 기관, 회계법인 | 높음 |
- 감사 유형은 시험 개요의 정의(내부=조직 통제 안, 외부=조직 통제 밖, 제3자=기업 통제 밖)로 구분한다. 독립성이 가장 높은 것은 제3자 감사이다.
- 감사인은 독립적이어야 한다. 감사 대상 시스템을 운영하는 사람이 그 시스템을 감사하는 선지는 오답이다.
- 감사는 문제를 찾고 보고하며, 조치 결정과 위험 수용은 경영진(자산 소유자)의 몫이다. "감사인이 직접 고친다"는 오답이다.
- 클라우드에서는 공급자를 직접 감사하기 어려우므로 SOC 2 Type 2 같은 제3자 보증 보고서를 검토하고, 보고서의 범위·기간·보완 이용자 통제를 확인하는 것이 가장 좋은 답이다.
- 감사를 시작할 때 가장 먼저 할 일은 목적·범위·기준을 정하는 계획 단계이다.
- 감사(기준 준수 확인)와 모의 침투(공격 가능성 확인)는 목적이 다르다. 문제의 질문이 "준수 여부"인지 "실제 침투 가능성"인지 보고 고른다.