ISMS-P 2.6.1 접근통제 High Risk

네트워크 접근통제가 적절히 수행되고 있는가?

ISMS-P 2.6.1은 네트워크에 대한 접근을 업무 목적에 따라 최소한의 범위로 제한하도록 요구합니다. 클라우드 환경에서는 서비스 계정, 보안 그룹, 네트워크 정책 등을 통해 인가된 대상만 필요한 범위 내에서 접근하도록 통제해야 합니다.

📋

ISMS-P 인증 기준

ISMS-P 2.6.1 접근통제 요구사항

2.6.1

접근통제

인증 기준 정의

"정보시스템과 개인정보 및 중요정보에 대한 접근은 인가된 사용자, 프로그램, 프로세스만으로 제한하고 비인가된 접근 시도를 탐지해야 한다."

📌 클라우드 환경 적용 포인트

컨테이너/Pod 단위 접근권한 분리
네임스페이스 기반 격리 정책
서비스 계정별 최소권한 부여
RBAC 정책의 적정성 검토

⚠️ 미준수 시 심사 영향

결함: 과도한 권한 부여로 최소권한 위반
결함: 네임스페이스 격리 정책 부재
권고: 접근권한 정기 검토 절차 미흡

📄 KISA ISMS-P 인증기준 안내서 ↗ ☁️ AWS K-ISMS 규정 준수 ↗

📰

실제 보안 사고 사례

접근권한 관리 미흡으로 발생한 실제 사고

2024.01

Microsoft 임원진 이메일 침해

MFA 미적용 계정 + 과권한 OAuth 앱을 통해 러시아 APT(Midnight Blizzard)가 Microsoft 임원진 및 보안팀 이메일에 1개월 이상 접근.

💡 교훈: 테스트 환경에도 최소권한 원칙 적용, 레거시 OAuth 앱 정기 점검 필요

출처: Cloud Security Alliance ↗

2024.05

Snowflake 165개 기업 연쇄 침해

필요 이상의 권한이 부여된 계정 탈취로 AT&T, Ticketmaster, Santander 등 165개 기업 침해. 3천만 개인정보 + 2,800만 신용카드 정보 유출.

💡 교훈: 서비스 계정 권한 범위 최소화, 정기적인 권한 검토 필수

출처: Cloud Security Alliance ↗

⚡

클라우드 환경의 위험

Kubernetes에서 접근통제가 위반되는 상황

ClusterRoleBinding (위험)

frontend

✓

backend

✓

data

✓

↑ 전체 네임스페이스 접근

클러스터 전체 네임스페이스에 권한 부여 → 네임스페이스 격리 무효화

RoleBinding (권장)

frontend

✓

backend

✗

data

✗

↑ 지정 네임스페이스만 접근

특정 네임스페이스에만 권한 부여 → 네임스페이스 격리 유지

🚨

발견 사례: frontend-deployer 계정에 ClusterRoleBinding 사용

edit Role 자체는 과권한이 아닙니다. 그러나 ClusterRoleBinding으로 바인딩되어 frontend 서비스 계정이 backend, data 등 모든 네임스페이스 리소스를 수정할 수 있습니다.

현재 상태 - 문제가 되는 설정

kind: ClusterRoleBinding  # ⚠️ 클러스터 전체 범위
metadata:
  name: frontend-deployer-binding
subjects:
  - kind: ServiceAccount
    name: frontend-deployer
    namespace: frontend
roleRef:
  kind: ClusterRole
  name: edit

ISMS-P 2.6.1 위반 사항

●

서비스 계정이 필요 범위 초과 접근 가능

●

최소권한 원칙 위반

●

네임스페이스 격리 정책 무효화

●

침해 시 전체 클러스터 피해 확산 위험

🔍

사전 탐지 방안

IaC 코드 분석 기반 배포 전 점검

ClusterRoleBinding 탐지 로직

판단 조건	조건 값	결과
👤 계정 유형	`kube-system` `kube-public`	✓ 통과
👤 계정 유형	일반 서비스 계정 (frontend, backend 등)	→ 권한 검사
🔑 권한 수준	`cluster-admin`	Critical - PR 즉시 차단
	`edit` `admin`	High - 차단 + Slack 알림
	`view`	Medium - 알림만

🔔

사후 대응 방안

런타임 모니터링 및 이상행위 탐지

ClusterRoleBinding 런타임 이벤트 대응 로직

판단 조건	조건 값	결과
📦 IaC 관리 여부	`Terraform State에 존재` 정상 IaC 배포	✓ 변경 이력만 저장
📦 IaC 관리 여부	`Drift 발생` 콘솔/kubectl 직접 변경	→ 상세 분석
⏰ 변경 상황 (Drift 발생 시)	`야간 (22~06시)` + `미등록 IAM`	Critical - PagerDuty 호출
	`10분 내 3건 이상` 단시간 다수 변경	High - Slack 즉시 알림
	`등록 IAM + 업무시간` 일반 Drift	Medium - Slack 알림 + 로깅

모든 알림에 포함되는 정보

변경된 바인딩 이름 영향받는 서비스 계정 변경 주체 (IAM) RoleBinding 전환 가이드

✓

조치 가이드

즉시 적용 가능한 권장 설정

❌ 삭제

frontend-deployer-binding ClusterRoleBinding

✓ 적용

frontend 네임스페이스 한정 RoleBinding

권장 설정 (복사하여 적용)

frontend-deployer-binding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding  # ✓ Namespace 범위로 변경
metadata:
  namespace: frontend  # ✓ frontend NS로 제한
  name: frontend-deployer-binding
subjects:
  - kind: ServiceAccount
    name: frontend-deployer
roleRef:
  kind: ClusterRole  # ClusterRole 참조는 가능
  name: edit  # RoleBinding이 범위를 제한
  apiGroup: rbac.authorization.k8s.io

💡 핵심: ClusterRole을 참조하더라도 RoleBinding을 사용하면 해당 네임스페이스로 권한이 제한됩니다. 별도의 커스텀 Role을 만들 필요 없이, 기존 edit ClusterRole을 재사용할 수 있습니다.

📚 참고 자료

☁️ EKS Best Practices - IAM ↗ 📘 Kubernetes RBAC 공식 문서 ↗ 🔒 AWS EKS Security Best Practices ↗

📊

리포트 방안

ISMS-P 심사 증적 및 정기 보고

📋 진단 항목

ClusterRoleBinding 총 개수
비시스템 계정 바인딩 수
RoleBinding 대체 가능 건수
신규 생성/변경 건수 (기간별)
미조치 항목 수

📅 리포트 주기

일간

변경 사항 알림

주간

취약점 현황 요약

월간

ISMS-P 증적 리포트

📤 발송 및 저장

발송 채널

Email Slack

저장소

S3 (5년 보관)

⚡

BSG 차별점

기존 도구가 놓치는 점검 영역

기존 도구 방식

Role 권한 패턴만 검사

cluster-admin Role 탐지
Wildcard (*) 권한 탐지
secrets, nodes 등 민감 리소스 접근

한계: edit Role처럼 권한이 과하지 않으면, ClusterRoleBinding이어도 탐지 못함

BSG 접근 방식

ISMS-P 관점 통합 점검

Binding 종류 자체를 검사
사전 탐지 + 사후 모니터링 통합
ISMS-P 증적 자동 생성

차별점: 인증 기준 관점에서 탐지 → 조치 → 증적 전 과정 자동화

← Cloud Security로 돌아가기