[ISMS] 접근제어 (개인공부)

요약

• 접근 제어는 자원의 중요도에 따라 영역을 분리한다.
• 분리한 영역에 대해 접근하는 것을 제어하고 로깅하고 증적한다.
• CSP마다 적용할 수 있는 방법들이 다르고, 지속적으로 방화벽 관리 등을 수행해야 한다.

내용

• 필요한 ISMS 정보보호대책 목록은 아래와 같다. (많다...)
  • 정보자산 분류 → 인증 범위 산정, 자산 데이터 정리, 현황 및 흐름 분석, 자산 재사용 및 폐기
  • 정보보호 정책 → 정보보호 정책 설정 및 위험 평가, 보호대책 선정/구현/공유, 정책 유지관리
  • 정보보호 조직 → 관리 체계 조직 마련 (회의록, 관리자 선정)
  • 외부자 보안 → 계약 관리, 보안 이행 관리, 현황 관리
  • 인적 보안 → 보안 서약, 보안 교육, 퇴직 및 직무변경 관리, 보안 위반 조치
  • 물리적 보안 → 보호 구역 지정, 출입통제, 보호구역 내 작업, 반출입 기기 통제, 업무환경 보안, 보조저장 매체 차단 정책, 관리 대장
  • 운영 보안 → 운영 현황 관리, 법적 요구사항 준수 검토, 개정 내부 공유, 관리체계 개선
  • 시스템 개발 보안
  • 암호 통제 → 암호키 관리, 계정 관리
  • 접근 통제 → 네트워크 접근, 원격접근통제, 인터넷 접속 통제 정책, 암호키 관리
  • 침해사고 관리
  • IT 재해복구

이전 다른 분류, 정책, 조직, 인적 보안, 물리 보안 등의 내용은 이번 접근 통제와 다르게 문서와 정책 위주이고, 접근 통제, 암호 통제야 말로 AWS 및 퍼블릭 CSP 사용에 있어 인증 심사의 가장 중요한 부분이라 생각한다.

아래 참고 자료를 정말 많이 참고했다 ( 저 분은 정말 대단한 분이다...)

메뉴얼 기반으로 내가 이해한 내용 기반으로 정리한 것은 아래와 같다.

• 네트워크 접근
  • 네트워크에 대한 비인가 접근 통제를 위한 IP관리, 단말 인증 등 관리 절차를 수립하여 이행하고, 업무 목적의 중요도에 따라 네트워크 분리 및 접근통제 적용 필요
  • 방화벽 설정 등을 계속 최신화 하는 지 증적 필요
  • 무선, 원격 접근, 인터넷 접근 제어 내용도 모두 포함되는 내용

- 영역 별 서브넷 분리 수행 ( Public , Private , DB ) 
    > Internet GW 는 Public 라우팅 설정 , Private, DB는 NAT GW 라우팅 설정

- 배스천 서버는 사내망 또는 내부망에서 접근 가능하게 바꾼다.
    > 아마 회사에서 사용하는 공인IP가 있을 것이다. 그것으로 설정하자
    > 외부에서 붙을 때는 VPN을 통해 내부망을 붙고 접근하게 하자 
        (VPN 접근 시에는 2 Factor 인증이 있다면 좋다고 한다)

- 방화벽 룰 중 Ingress 부분에 대해 0.0.0.0/0 (ANY)가 있는 지 확인 한다.
    > 만약 특정 지울 수 없는 상황이라면 앞에 LoadBalancer라도 붙여서 한 번 숨기는 것이 좋을 듯

- 방화벽 룰 중 Egress 부분에 대한 제어 필요 
    > WhiteList는 AWS 에서는 SG-rule로 관리하고
    > BlackList는 NACL로 관리하는 것이 좋다 (사용할 수 있는 갯수 제한이 있다 참고 필요)

- 서비스 콘솔 접근 제어 필요 
    > VPN > VDI > 서비스 콘솔 접근 제어가 필요 (이것은 굳이???)
     > AWS 콘솔도 모두 접근이 가능하기 때문에, 사내 IP 주소만 접근하도록 제어하는 것이 좋다.
    > 소스 IP 바탕으로 IAM에 등록 할 수 있다. (계정 탈취 되어도 1차 안심)

- EBS에 대한 접근 권한을 확인 해야함
    > 암호화 되어 있는 지 확인 (문제가 없는 지 확인 필요 - 추후 복호화,인스턴스 변경 가능한지)
    > 불필요한 읽기, 쓰기 권한이 있는 지 확인

- 불필요한 IP/PORT 제거 및 현행화 (당연한 소리)

- 각 자원 엑세스 권한 및 로깅 확인 
    > 이 부분이 어려운 부분인 것 같다.
    > 로깅 설정을 추가하고 S3에 증적해놓으면 

추가 내용 

- nslookup을 해도 Private IP가 노출되면 안되도록 설정해야한다.. (?? 오카방 출처)
    > 이건 어떻게 하는 지 확인 좀 해봐야겠다.
- 도커 베이스 이미지 또는 AMI를 하드닝 한다 (오카방 출처)
    > 이후 ISMS 갱신 때 도커 베이스 이미지와 AMI가 하드닝 되어 있으면 스크립트에 걸리지 않는다
    > 이건 좀 꿀팁인 듯

# IAM 참고 소스 코드
{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
            "NotIpAddress": {
                "aws:SourceIp": "123.123.123.123"
            }
        }
 }

• 암호키 관리
  • 암호키의 안전한 생성,이용,보관,배포,파기를 위한 관리 절차를 수립, 이행하고 필요 시 복구 방안 마련해야한다.

- Access Key는 90일 주기 정도로 계속 갱신이 되면 좋다.
    > AWS에서 TrustedAdvisor 부분 확인하면 알 수 있음 
- Key 관리 절차 수립 (생성 방안, 보관 방안, 로깅 증적 방안 -> aws 콘솔에서 보임)
- 복구 방안은 파기 후 재발급 원칙으로 가면 끝..

배울 점 및 생각

• 접근 통제 부분에 대해서는 정말 많은 내용이 있다 이 부분은 계속 추가하고 정리해야 할 것 같다.
• SK 인포섹에서 제공하는 자료를 참고하는 것도 좋을 것 같다.

추후 해야할 것

• 나머지 ISMS 정책 준비할 것을 정리하고 끝내자..

참고자료

(ISMS-P) 2.6 접근 통제

(ISMS-P) 2.6 접근 통제

AWS 관리 콘솔 접근 제어 (based on Source IP)

AWS 관리 콘솔 접근 제어 (based on Source IP)

EBS 볼륨에 대한 기본 암호화 선택 기능 출시 (서울 리전 포함) | Amazon Web Services

EBS 볼륨에 대한 기본 암호화 선택 기능 출시 (서울 리전 포함) | Amazon Web Services

OSS가이드.pdf

17.53MB