컴플라이언스
IT 위키
더 많은 작업
- Compliance; 규제 준수, 준거성
- 조직이 지켜야 할 법률·규제·계약·업계 표준·내부 정책을 식별하고, 그 요구를 실제로 지키고 있음을 증적으로 보여 주는 활동
컴플라이언스는 "무엇을 지켜야 하는가"를 정하는 일과 "지키고 있음을 증명하는" 일로 나뉜다. 정보보호 측면에서는 개인정보 보호법 같은 법률, 감독기관의 고시, 고객과 맺은 계약, PCI DSS 같은 업계 표준, 그리고 조직이 스스로 정한 정보보호 정책이 모두 요구사항의 원천이 된다. 이를 위반하면 과징금·형사처벌, 계약 해지, 인증 취소, 평판 손상으로 이어지므로 컴플라이언스는 위험 관리의 한 축이다.
CISSP 시험 개요(2024)에서는 1.4 항목이 "계약·법률·업계 표준·규제 요구사항"을, 6.2 항목이 보안 통제 테스트의 하나로 "컴플라이언스 점검(compliance checks)"을 다룬다.
| 층위 | 근거 | 구속력 | 예 |
|---|---|---|---|
| 법률 | 국회가 제정한 법 | 강제. 위반 시 형사처벌·과징금 | 개인정보 보호법, 정보통신망법, 전자금융거래법, SOX, HIPAA, GLBA, GDPR |
| 하위 법령·규제 | 시행령·시행규칙, 감독기관 고시 | 강제. 감독기관 검사·제재 | 개인정보의 안전성 확보조치 기준, 전자금융감독규정 |
| 계약 | 당사자 간 합의 | 계약상 의무. 위반 시 손해배상·계약 해지 | PCI DSS(카드 브랜드와 가맹점·매입사 계약을 통해 적용), SLA, 클라우드 이용 약관, 감사권 조항 |
| 업계 표준·인증 | 표준화 기구, 업계 단체 | 자발적이지만 고객·입찰 조건이 되면 사실상 강제 | ISO/IEC 27001, ISMS-P, SOC 2, FedRAMP |
| 내부 정책 | 경영진 승인 문서 | 조직 내부 구속. 위반 시 징계 | 정보보호 정책, 표준, 절차, 지침 |
상위 층위의 요구는 하위 층위가 낮출 수 없다. 내부 정책은 적용되는 법·계약 요구를 모두 담은 상태에서 조직 사정에 맞게 더 엄격하게 정할 수 있다.
| 구분 | 규제 | 정보보호와 관련된 핵심 요구 |
|---|---|---|
| 한국 | 개인정보 보호법 | 개인정보 처리 원칙, 안전성 확보조치, 유출 통지·신고, 국외 이전 통제, 과징금 |
| 한국 | 정보통신망법 | 정보통신망의 안정성 확보, 침해사고 신고, 일정 기준 사업자의 정보보호 관리체계(ISMS) 인증 의무(제47조) |
| 한국 | 전자금융거래법·전자금융감독규정 | 금융회사등의 안전성 확보 의무(법 제21조)와 금융위원회가 정하는 인력·시설·전자적 장치 기준 |
| 한국 | ISMS-P 인증 | 정보통신망법 제47조와 개인정보 보호법 제32조의2에 근거한 관리체계 인증. 인증 유효기간 3년 |
| 미국 | SOX(사베인스-옥슬리법, 2002) | 상장사 재무보고 내부통제의 경영진 평가와 외부감사인 검증. 재무 시스템의 접근통제·변경 관리가 IT 통제(ITGC)로 점검된다 |
| 미국 | HIPAA(1996) | 의료 정보(PHI)의 프라이버시·보안 규칙, 유출 통지 |
| 미국 | GLBA(1999) | 금융기관 고객정보 보호. FTC Safeguards Rule이 정보보호 프로그램 수립을 요구 |
| EU | GDPR | 개인정보 처리 원칙, 정보주체 권리, 72시간 유출 통지, 국외 이전 통제. 나라별 비교는 주요국 개인정보 보호법 참고 |
- 요구사항 식별: 사업 지역·업종·고객 계약을 기준으로 적용 법규와 표준 목록(법규 대장)을 만든다. 법 개정을 추적할 담당자를 정한다.
- 통제 매핑: 각 요구를 조직의 통제 항목에 연결한다. 하나의 통제(예: 다중 인증)가 여러 규제를 동시에 충족하도록 보안 통제 프레임워크를 공통 기준으로 쓰면 중복 감사를 줄일 수 있다.
- 이행과 증적: 통제가 운영된다는 증거(정책 승인 기록, 접근 권한 검토 결과, 로그, 교육 이수 기록, 점검 보고서)를 보존 기간과 함께 관리한다. 증적이 없으면 감사에서는 하지 않은 것으로 본다.
- 점검과 감사: 내부 점검, 내부 감사, 외부 인증 심사, 감독기관 검사로 이행 여부를 확인한다. 자세한 구분은 보안 감사 참고.
- 시정과 보고: 부적합 사항은 원인, 조치 계획, 기한, 책임자를 정해 추적하고 경영진과 이사회에 보고한다. 당장 고칠 수 없으면 위험 수용 또는 예외 승인 절차를 거친다.
6.2 항목의 컴플라이언스 점검은 시스템이 정해진 보안 구성 기준을 실제로 따르고 있는지 기술적으로 확인하는 테스트이다.
- 구성 기준 점검: 운영체제·DB·네트워크 장비 설정을 조직의 보안 기준선이나 공인 벤치마크와 비교한다. 비밀번호 정책, 불필요한 서비스, 감사 로그 설정, 패치 수준이 대표 항목이다.
- SCAP 자동 점검: SCAP(Security Content Automation Protocol)은 NIST가 관리하는 보안 자동화 규격 묶음이다. XCCDF(점검 목록 형식), OVAL(시스템 상태 판정 언어), CPE(플랫폼 식별), CCE(구성 항목 식별), CVE·CVSS(취약점 식별·점수) 등을 조합해, 기계가 읽을 수 있는 점검 콘텐츠로 여러 제품에서 같은 결과를 얻게 해 준다. NIST SP 800-126 Rev. 3은 SCAP 1.3을 정의하고, NIST는 SCAP 1.4를 개발 중이다.
- 지속적 점검: 연 1회 점검 대신 구성 변경을 계속 감시해 기준 이탈(configuration drift)을 바로 잡는다. 지속적 보안 모니터링의 한 구성 요소이다.
- 주의: 점검 도구의 "적합" 결과는 기술 설정이 맞다는 뜻일 뿐, 업무 절차나 관리적 통제까지 충족했다는 뜻은 아니다.
규제는 최소 기준이고, 대개 공표 시점의 위협을 바탕으로 만들어진다. 인증을 받은 조직도 침해를 당한다. 감사 범위 밖의 시스템, 표본 점검의 한계, 점검 시점에만 맞춰 놓은 설정이 흔한 원인이다. 반대로 위험 평가에 근거한 보안 프로그램은 대부분의 규제 요구를 자연스럽게 충족한다. 따라서 보안 책임자는 "감사를 통과하는 것"이 아니라 "위험을 허용 수준으로 낮추고, 그 결과로 준수를 입증하는 것"을 목표로 삼는다.
| 구분 | 준수 중심 접근 | 위험 중심 접근 |
|---|---|---|
| 질문 | 요구사항을 충족했는가 | 이 위험을 충분히 줄였는가 |
| 범위 | 규제 대상 시스템 | 사업에 중요한 모든 자산 |
| 시점 | 감사·심사 주기 | 지속적 |
| 결과 | 인증서, 감사 의견 | 위험 감소와 그 증거 |
- 법률·규제는 강제, 계약(PCI DSS 포함)은 계약상 의무, 업계 표준·인증은 원칙적으로 자발적이다. PCI DSS는 법이 아니라 계약으로 적용된다는 점을 구분한다.
- 새 규제가 생기면 가장 먼저 할 일은 적용 여부와 범위 확인(법무·컴플라이언스 부서와 함께)이다. 곧바로 기술 도입부터 고르는 보기는 흔한 오답이다.
- 감사에서 통제를 증명하는 것은 문서화된 증적이다. "했지만 기록이 없다"는 미이행으로 판정된다.
- 컴플라이언스 점검은 구성 기준 대비 일치 여부를 보는 테스트이고, 자동화 표준은 SCAP이다.
- 준수(compliance)를 보안(security)과 동일시하는 보기는 오답이다. 준수는 최소선이다.
- 여러 규제가 겹치면 공통 통제 프레임워크로 매핑해 한 번 이행·여러 번 증명한다.
- Security Content Automation Protocol (SCAP) – NIST CSRC
- NIST SP 800-126 Rev. 3, The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.3 – NIST
- Gramm-Leach-Bliley Act – Federal Trade Commission
- Public Law 107-204 (Sarbanes-Oxley Act of 2002) – U.S. Government Publishing Office
- 정보통신망 이용촉진 및 정보보호 등에 관한 법률 – 국가법령정보센터