서론
이번에는 선정한 통제항목을 컴플라이언스팀이 실제로 콘솔을 열고 하나씩 확인해보며, 현재 상황과 점검한 내용을 기록했다. IAM·Logging·Detection은 필자가, S3/Data·Incident Response는 팀 내 다른 담당자가 같은 방식으로 점검했다. 또한 이 글은 팀 블로그에 공개되는 자료로, 계정 ID·액세스 키 등 민감정보가 포함된 화면은 캡처를 생략했다. 해당 캡처를 포함한 전체 증적 자료는 추후 프로젝트 제출용 문서에 별도로 첨부할 예정이다.
점검 방법
각 통제항목은 아래 기준으로 정리했다.
- 요구사항
- 근거
- 점검 대상
- 검증 방법
- 결과
인프라를 직접 구축한 게 아니라, 이미 만들어진 걸 기준에 맞는지 검증하는 컴플라이언스 관점에서 접근했다는 점을 먼저 밝힌다. 그래서 콘솔 조회 권한이 없어 막힌 항목들도 결과로 그대로 남겼다.
(1) IAM(계정과 권한)
IAM-01
요구사항: 모든 사용자 계정(관리자 포함)에 MFA가 적용되어 있는지 점검
근거: ISMS-P 2.5.3 / 개인정보 보호법 제29조, 안전성 확보조치 기준 제5·6조
확인 방법: IAM 콘솔 > 사용자 목록의 MFA 컬럼 직접 확인
결과: 일부 미흡
→ IAM 사용자 9명 중 6명은 MFA(가상 MFA 5명, 패스키 1명) 적용, 3명은 미적용 상태
IAM-02
요구사항: IAM 정책이 과도한 권한을 부여하고 있지 않은지 점검
근거: ISMS-P 2.5.1 및 2.6.1, 개인정보 보호법 제29조, 안전성 확보조치 기준 제5조
확인 방법: IAM 콘솔에서 고객 관리형 정책 JSON 직접 열람, Action/Resource에 와일드카드(*)가 있는지 확인
결과: 일부 미흡 → kintoun-secops-infra-wazuh-ec2-ssm-role 정책에서 Action은 특정 작업으로 제한되어 있었지만, Resource가 전체(*)로 설정됨. 액션 자체는 통제되고 있어 심각도는 낮지만, 리소스 범위를 좁히는 개선 필요
IAM-03
요구사항: Root 계정이 일상 업무에 사용되지 않고 있는지 점검
근거: ISMS-P 2.5.5, 개인정보 보호법 제29조, 안전성 확보조치 기준 제5조
확인 방법: CloudTrail 이벤트 기록에서 사용자 이름 "Root"로 검색
결과: 충족 → 검색 결과 일치하는 항목 없음. 프로젝트 기간 동안 Root 계정이 일상 업무에 사용된 이력 없음
IAM-04
요구사항: 프로젝트 기간 중 발급된 IAM 계정&액세스키 중 미사용 상태로 방치된 것이 있는지 점검
(※ 원 기준은 90일 미사용이나, 14주 프로젝트 기간상 적용 불가하여 프로젝트 기간 내 방치 여부로 조정)
근거: ISMS-P 2.5.6, 개인정보 보호법 제29조, 안전성 확보조치 기준 제5조
확인 방법: IAM Credential Report 및 사용자 목록의 마지막 활동일 확인
결과: 충족 → 계정 전체 확인 결과 90일 이상 미사용 계정 없음(최대 미사용 기간 12일).
1개 계정은 생성 후 아직 실사용 이력 없음(참고사항)
IAM-05
요구사항: 팀 내 개인정보나 로그 접근 권한이 직무별로 분리되어 있는지 점검
근거: ISMS-P 2.5.1, 개인정보 보호법 제29조, 안전성 확보조치 기준 제5조
확인 방법: IAM 콘솔 > 그룹 목록과 소속 사용자 대조
결과: 충족 → 그룹별로 팀원이 소속되어 있고, 권한이 직무(공격/인프라/탐지 등)별로 분리되어 있음
(2) Logging(로그 관리)
Log-01
요구사항: 접속기록이 1년 이상 보관되도록 보관주기가 설정되어 있는지 점검
근거: ISMS-P 2.9.4(로그 및 접속기록 관리), 안전성 확보조치 기준 제8조
확인 방법: S3 버킷 라이프사이클 정책 확인
결과: 확인 불가 → 컴플라이언스팀 계정에 로그 저장 버킷(cloudtrail-logs) 접근 권한(s3:ListBucket)이 없어 보관주기 설정값 직접 확인 불가. 인프라팀 확인 또는 조회 권한 부여 필요
Log-02
요구사항: 개인정보 처리 관련 로그(조회/다운로드/수정/삭제)가 별도 기록되고 있는지 점검
근거: ISMS-P 2.9.4, 안전성 확보조치 기준 제8조
확인 방법: CloudTrail 콘솔 > 추적 > 데이터 이벤트 섹션 확인
결과: 충족 → CloudTrail 추적 설정에서 데이터 이벤트(S3)가 "모든 이벤트 로깅"으로 활성화됨. S3 저장 개인정보에 대한 조회·다운로드·수정·삭제가 모두 기록되고 있음
Log-03
요구사항: 로그가 위변조되지 않도록 무결성이 보장되고 있는지 점검
근거: ISMS-P 2.9.4, 안전성 확보조치 기준 제8조
확인 방법: CloudTrail 추적 설정에서 로그 파일 검증 활성화 여부 확인
결과: 충족 → CloudTrail 추적 화면에서 "로그 파일 검증" 활성화 확인
Log-04
요구사항: 로그 저장소(S3)에 대한 접근이 최소 인원으로 제한되어 있는지 점검
근거: ISMS-P 2.6.1 및 2.9.4
확인 방법: IAM 정책에서 로그 버킷 관련 권한 보유자 확인
결과: 확인 불가 → LOG-01과 동일한 사유로 S3 버킷 직접 접근 불가. IAM 고객 관리형 정책으로도 로그 버킷 접근 권한자 특정 어려움. 인프라팀에 버킷 정책 및 접근 가능 IAM 주체 목록 요청 필요
Log-05
요구사항: 주요 시스템(IAM, EC2 등)의 로그가 실시간 모니터링 대시보드로 시각화되어 있는지 점검
근거: ISMS-P 2.9.4 및 2.11.1
확인 방법: CloudWatch 대시보드 확인
결과: 충족 → 주요 시스템 지표를 시각화한 CloudWatch 대시보드를 구축 중이며 상시 확인 가능
CloudTrail이 기록한 API 호출 이벤트 원본 JSON을 CloudWatch Logs에서 그대로 조회하는 화면을 확인할 수 있음.
(3) Detection(탐지 체계)
※ DET 영역은 원래 GuardDuty 기준으로 점검을 설계했으나, 실제 확인 결과 GuardDuty가 활성화되어 있지 않은 것으로 나타났다. SIEM으로 사용 중인 Wazuh에서도 재확인을 시도했다.
DET-01
요구사항: 비정상 로그인 시도 탐지 체계가 구성되어 있는지 점검
근거: ISMS-P 2.11.1(보안 사고 예방 및 대응체계 구축), 2.11.2(취약점 점검 및 조치)
확인 방법: GuardDuty 콘솔 확인 or Wazuh "Amazon Web Services" 대시보드에서 관련 키워드 검색
결과: 확인 불가 → GuardDuty 콘솔에는 "시작하기" 화면만 표시되어 미활성화로 보임.
Wazuh 대시보드에서도 guardduty, cloudwatch 키워드로 최근 12일간 검색 결과 없음
다음 점검 시 확인 필요: Wazuh 매니저 aws-s3 wodle 설정에 GuardDuty 서비스 등록 여부 / rule.groups 필터값과 실제 수집 규칙 그룹명 일치 여부 / 로그인 실패 관련 규칙이 Wazuh 규칙셋에 존재하는지 여부
DET-02
요구사항: 개인정보가 저장된 리소스에 대한 비정상적 대량 조회·다운로드가 탐지되는지 점검
근거: ISMS-P 2.11.1 및 2.9.4, 안전성 확보조치 기준 제8조
확인 방법: GuardDuty S3 Protection 활성화 여부 + Wazuh 대시보드 검색
결과: 확인 불가 → DET-01과 동일한 이유로 GuardDuty S3 Protection 활성화 여부 미확인
Wazuh에서도 관련 이벤트 검색 안 됨
다음 점검 시 확인 필요: CloudTrail 데이터 이벤트 로깅 실제 활성화 여부(LOG-02에서는 확인됨, 파이프라인 연결 여부가 관건), Wazuh로 CloudTrail 이벤트가 전송되는 파이프라인 구성 여부 인프라팀 확인
DET-03
요구사항: 권한 상승 시도나 비인가 IAM 정책 변경이 실시간으로 탐지되는지 점검
근거: ISMS-P 2.11.1 및 2.5.1
확인 방법: GuardDuty Finding 유형 확인 + Wazuh에서 IAM 정책 변경 이벤트 검색
결과: 확인 불가 → AttachUserPolicy, CreatePolicy 등 IAM 이상행위 관련 이벤트가 Wazuh에서 확인되지 않음
다음 점검 시 확인 필요: CloudTrail에서 IAM 정책 변경 이벤트 실제 기록 여부, Wazuh IAM 이상행위 규칙활성화 여부
(4) S3/Data(저장 데이터 보호)
S3-01
요구사항: S3 버킷에 대한 퍼블릭 액세스가 차단되어 있는지 점검(계정 단위 및 버킷 단위)
근거: ISMS-P 2.6.1(접근권한 관리), 개인정보 보호법 제29조, 안전성 확보조치 기준 제5조
확인 방법: S3 콘솔 > 버킷 > 권한 탭 > 퍼블릭 액세스 차단 4개 항목 확인, 버킷 정책·ACL의 Principal 확인
결과: 확인 불가 → s3:ListAllMyBuckets 등 S3 조회 권한 자체가 없어 버킷 목록 접근 불가
S3-02
요구사항: 개인정보 및 중요정보가 저장되는 S3 버킷에 저장 시 암호화가 적용되어 있는지 점검
근거: ISMS-P 2.7.1(암호정책 적용), 개인정보 보호법 제29조, 안전성 확보조치 기준 제7조
확인 방법: S3 콘솔 > 버킷 > 속성 > 기본 암호화(SSE-S3/SSE-KMS) 여부 확인
결과: 확인 불가 → S3-01과 동일한 사유로 확인 불가
S3-03
요구사항: S3로 데이터 전송 시 HTTPS(SSL/TLS) 암호화 통신이 강제되고 있는지 점검
근거: ISMS-P 2.7.1, 안전성 확보조치 기준 제7조(전송 구간 암호화)
확인 방법: 버킷 정책 JSON에서 aws:SecureTransport: false 조건에 대한 Deny 구문 존재 여부 확인
결과: 확인 불가 → 동일한 사유로 확인 불가
S3-04
요구사항: 중요정보가 저장된 S3 버킷에 대해 버전관리 및 백업·복구 절차가 수립·적용되어 있는지 점검
근거: ISMS-P 2.9.3, 안전성 확보조치 기준 제11조(재해·재난 대비 안전조치)
확인 방법: S3 콘솔 > 버킷 > 속성 > 버전관리(Versioning), 복제 규칙(Replication) 설정 확인
결과: 확인 불가 → 동일한 사유로 확인 불가
S3-05
요구사항: 개인정보 보유기간이 경과하거나 처리목적이 달성된 데이터가 S3 라이프사이클 정책 등을 통해 지체 없이 파기되고 있는지 점검
근거: ISMS-P 3.4.1, 개인정보 보호법 제21조, 표준 개인정보 보호지침 제10조
확인 방법: S3 콘솔 > 관리 탭 > 수명 주기 규칙의 만료 규칙 존재 여부, Object Lock 설정 확인
결과: 확인 불가 → 동일한 사유로 확인 불가
(5) Incident Response(사고대응 체계)
※ 앞선 영역들과 달리 권한이 없어서 확인은 못한 부분이 아닌, 체계 자체가 없다는 게 확인된 항목이 많았다.
IR-01
요구사항: 침해사고 및 개인정보 유출사고에 대비한 예방·대응체계와 절차가 수립되어 있는지 점검
근거: ISMS-P 2.11.1, 개인정보 보호법 제29조·제34조
확인 방법: 침해사고 대응절차서·비상연락망 문서 확인, SNS 알림 구독 설정 콘솔 확인
결과: 미준수 → 침해사고 대응절차서·비상연락망 문서 부재, SNS 알림 주제 미등록. 사고 발생 시 대응 체계 자체가 수립되어 있지 않음
IR-02
요구사항: 정보시스템(EC2, S3 등)의 보안 취약점을 정기적으로 점검하고 발견된 취약점을 신속히 조치하는 체계가 운영되고 있는지 점검
근거: ISMS-P 2.11.2, 안전성 확보조치 기준 제4·6조
확인 방법: Security Hub / Inspector 콘솔 > 활성화 여부, 최근 스캔 결과 및 조치 이력 확인
결과: 확인 불가 → Security Hub는 "활성화 상태를 가져오지 못했습니다" 오류, Inspector는 inspector2:BatchGetAccountStatus 권한 없음으로 모두 상태 조회 불가
IR-03
요구사항: 내·외부 침해시도 및 이상행위를 실시간으로 탐지·분석하는 모니터링 체계가 구축되어 있는지 점검
근거: ISMS-P 2.11.3, 안전성 확보조치 기준 제8조
확인 방법: GuardDuty 콘솔 활성화 여부, Finding 발생 및 대응 이력 확인
결과: 미준수 → GuardDuty 온보딩 화면 확인, 권한 문제가 아닌 실제 미활성화로 확인됨. Detection 섹션확인 불가 결과와 이어지므로, 이상행위 실시간 탐지 체계가 부재한 상태임이 명확해짐
IR-04
요구사항: 침해사고 발생 시 탐지→분석→차단→복구→보고 단계별 대응 및 복구 절차가 수립되어 있고 실제로 이행 가능한지 점검
근거: ISMS-P 2.11.5, 개인정보 보호법 제29조
확인 방법: 사고대응 절차서의 단계별 조치사항 명시 여부, CloudTrail에서 실제 조치 이력(DeleteAccessKey, AuthorizeSecurityGroupIngress/RevokeSecurityGroupIngress, StopInstances, CreateSnapshot 등) 확인
결과: 미준수 → CloudTrail에서 사고 대응성 조치 이력 전무. IR-01에서 확인된 것처럼 절차서 자체가 없어 실제 이행 가능 여부도 판단 불가
IR-05
요구사항: 개인정보 유출이 확인된 경우 법정 기한 내에 정보주체 통지 및 개인정보보호위원회·전문기관 신고 절차가 수립되어 있는지 점검
근거: 개인정보 보호법 제34조, ISMS-P 2.11.1
확인 방법: 유출 통지문 양식 및 발송 이력, 개인정보보호위원회 및 KISA 신고 이력 확인(유출시)
결과: 미흡 → 법 제34조 및 시행령 제40조에 대한 법적 근거와 통지 필요항목 조사는 완료(회의 제출 자료 존재). 다만 실제 활용 가능한 통지문 양식, 유출 규모·항목 확정 기준, 신고 프로세스는 미수립.
종합 정리
영역 | 충족 | 미흡 | 확인 불가 | 미준수 |
IAM (5개) | 3 | 2 | 0 | 0 |
Logging (5개) | 3 | 0 | 2 | 0 |
Detection (3개) | 0 | 0 | 3 | 0 |
S3/Data (5개) | 0 | 0 | 5 | 0 |
Incident Response (5개) | 0 | 1 | 1 | 3 |
Insight
- 설정 부분에서 놓쳤던 문제
IAM-01의 MFA 미적용, IAM-02의 정책 문제같은 경우는 직접 콘솔창에 들어가 하나하나 확인해보면서 지금 우리팀의 정책들과 상황들을 파악하고 발견할 수 있었다.
- 컴플라이언스팀의 권한 자체의 문제
S3 버킷 접근 권한이 없어 LOG-01·LOG-04·S3 영역 6개 항목 대부분을 직접 확인하지 못했다. 이는 동시에 인프라팀과 컴플라이언스팀의 권한이 실제로 분리되어 있다는 것도 확인할 수 있는 부분이었다. 하지만 이후 감사·점검을 위한 최소한의 조회 권한을 따로 받는 것이 필요해 보인다.
- 탐지 체계와 사고대응은 미구축 문제
Detection 영역은 권한 문제로 확인 불가에 그쳤지만, IR 영역에서는 같은 GuardDuty 미활성화가 권한 문제가 아니라 실제 미구축으로 보였다. IR-01(대응절차서 부재), IR-03(탐지체계 부재), IR-04(모의훈련 이력 없음), IR-05(대응 조치 이력 없음)까지 확인 불가로 이어지는 것을 보면 아직 탐지부터 사고대응까지 이어지는 체계 자체의 구축이 미흡하다는 것을 확인할 수 있었다.
중간발표회 이후에는 해당 내용의 확인과 실행이 필요해보인다.
- GuardDuty 활성화 여부 인프라팀 확인 요청
- S3 버킷·로그 저장소 조회 권한 컴플라이언스팀에 부여 요청
- Wazuh 규칙셋(rule id) 목록 확인 후 DET 항목 재점검
- MFA 미적용 계정 개선
- 개인정보 유출 통지문 양식 및 신고 프로세스 수립
