2017년 8월 2일 수요일

1-2. AWS 보안 모범 사례

[운영 체제와 애플리케이션 보호]
0. AMI 개념
  - 아마존 머신 이미지 : 클라우드의 가상 서버인 인스턴스를 시작하는 데 필요한 정보를 제공함
  - AMI의 포함된 내용
    ~ 인스턴스 루트 볼륨 템플릿(예 : 운영체제, 애플리케이션 서버, 애플리케이션)
    ~ 인스턴스에 연결할 볼륨을 지정하는 블록 디바이스 매핑
    ~ AMI를 사용하여 인스턴스를 시작할 수 있는 AWS 계정을 제어하는 시작 권한
  - Amazon Linux AMI
    ~ EC2에서 실행되는 애플리케이션을 위한 안정적인 고성능 실행 환경
    ~ 무료 및 표준 패키지에 대한 리포지토리 액세스 가능
    ~ yum 레포지토리를 이용하여 실행 중인 인스턴스에 최신 구성 요소를 업데이트 가능
    ~ CLI, EC2 API 및 AMI 도구, ELB 등과 같이 AWW 서비스와 쉽게 통합할 수 있는 패키지 포함
1. AMI 게시 전 정리 작업
  - 보안성이 낮은 어플리케이션 비활성화
  - 필수적이지 않은 네트워크 서비스 비활성화
  - 디스크 및 구성 파일에서 모든 AWS 자격 증명 및 타사 자격 증명 안전하게 삭제
  - 시스템에서 추가 인증서 또는 키 구성 요소를 안전하게 제거
  - 설치된 소프트웨어가 기본 내부 계정과 암호를 미사용
2. Linux/UNIX AMI 보안 유지
  - sshd가 퍼블릭 키 인증만 허용하도록 구성 (sshd_config 에서 PubkeyAuthentication을 Yes, PasswordAuthentication을 No)
  - 인스턴스를 만들 때 고유 SSH 호스트 키를 생성함
  - 로그인에 사용할 수 없고 기본 암호를 보유할 수 없도록 모든 사용자 계정의 암호를 제거하고 비활성화함
  - 모든 사용자 SSH 퍼블릭 및 프라이빗 키 페어를 안전하게 삭제
  - 민감한 데이터가 포함된 모든 셸 기록과 시스템 로그 파일을 안전하게 삭제
3. 자동 구성
  - 보안 소프트웨어 업데이트 : AMI의 패치 수준 이상의 최신 패치, 서비스 팩 및 중요 업데이트를 설치함
  - 초기 애플리케이션 패치 : AMI로 포착된 현재 애플리케이션 수준 빌드 이상의 애플리케이션 수준 업데이트를 설치
  - 원격 보안 모니터링 및 관리 시스템에 인스턴스를 등록함

[맬웨어(악성 소프트웨어)로부터 시스템 보호]
  - 신뢰할 수 있는 AMI만 사용 (타사 AMI 사용 시 주의)
  - 신뢰할 수 있는 소프트웨어 (신뢰할 수 있는 공급자 및 소프트웨어만 설치)
  - 신뢰할 수 있는 소프트웨어 디포 (사용자가 설치 및 사용할 수 있는 신뢰할 수 있는 소프트웨어를 제공하는 자체 내부 소프트웨어 디포를 설정하는 것이 좋음)
  - 사용자가 작업을 수행하는데 필요한 최소 권한의 원칙을 부여
  - 패칭 : 외부로 연결되는 시스템과 내부 시스템을 최신 보안 수준으로 패칭함
  - 봇네트 : 기존의 바이러스, 트로이 목마 또는 웜 전파 등에 의한 감염이 개별 인스턴스 이상으로 퍼지고 더 넓은 플릿을 감염시키는 경우 원격 공격자가 제어할 수 있는 감염된 호스트 네트워크인 봇네트를 만드는 악성 코드가 포함될 수 있음
  - 스팸 : 감염된 시스템은 공격자들에 의해 대량의 원치 않는 메일을 전송하는데 사용될 수 있음, 따라서 SMTP 오픈 릴레이를 피함
  - 안티바이러스/스팸방지 소프트웨어, 호스트 IDS 소프트웨어(OSSEC 등 파일 무결성 확인 및 루트킷 탐지 소프트웨어 등의 호스트 기반 IDS 소프트웨어를 설치함)

[손상 및 참해 완화]
1. 사례
  - 패칭되지 않은 Amazon EC2 인스턴스가 감염되어 봇네트 에이전트가 될 수 있음
  - 의도하지 않은 침해 : 웹 크롤러를 DOS 공격자로 분류할 수 있음.
  - 2차적 침해 : S3 버킷에 맬웨어 피일을 게시 가능성 있음
  - 허위 불만 : 인터넷 사용자가 합법적인 활동을 침해로 오해하는 경우가 있음
2. 추가 애플리케이션 보안 사례 사용
  - 암호, SNMP 커뮤니티 문자열 및 보안 구성 등 공급업체가 제공한 기본값은 새 AMI를 생성하기 전이나 새 애플리케이션을 배포하기 전에 반드시 변경함
  - 불필요한 사용자 계정은 제거 또는 비활성화함
  - 시스템 기능의 필요에 따라 안전한 필수 서비스, 프로토콜, 데몬 등만 활성화
  - 스크립트, 드라이버, 기능, 하위 시스템, EBS 볼륨 및 불필요한 웹 서버 등을 비활성화 또는 제거함
3. 시스템과 애플리케이션에 대한 관리자 액세스를 위해 어려운 암호화 메커니즘을 사용하여 모든 비콘솔 관리자 액세스를 암호화합니다. SSH, 사용자 및 사이트별 IPSec VPN 또는 SSL/TLS 등의 기술을 사용하여 원격 시스템 관리의 보안을 강화합니다.

[보안 영역 조정 및 네트워크 세분화 사용]
- Amazon VPC 사용, 각 워크로드 또는 조직 개체의 격리된 네트워크를 정의
- 보안 그룹을 사용하여 기능과 보안 요구 사항이 비슷한 인스턴스에 대해 액세스 관리하는 방법(허용 및 설정된 모든 TCP 세션 또는 UDP 통신 채널에 대해 양쪽 방향으로 방화된 규칙을 활성화하는 상태 저장 방화벽)
- 네트워크 액세스 제어 목록(NACL) : IP 트래픽 상태 비저장 관리 허용 (IP 프로토콜을 통해 세분화된 제어와 TCP 및 UDP의 IP 주소 및 포트에 대한 소스/대상 단위 제어를 가능하게 함)
- 호스트 기반 방화벽 사용(각 인스턴스에 대한 액세스를 제어하는 방법)
- 트래픽 흐름에 위협 방지 계층을 만들고 모든 트래픽 영역을 통과하게 함

[위협 방지 계층 구축]
1. Amazon VPC 인프라
  - 로드 밸런서의 다중 계층 지원
  - 다중 IP 주소 지원 : 위협 방지 게이트웨이가 여러 인스턴스로 구성된 프레젠테이션 계층을 보호하는 경우 하나의 보안 게이트웨이를 사용해야함
  - 다중 ENI 지원
2. 클라우드상의 계층화된 네트워크 방어
  - 퍼블릭 서브넷(ELB) ~ 위협 방지 계층 ~ 프레젠테이션 계층 ~ 애플리케이션 계층 ~ 데이터 계층

[테스트 보안]
- 외부 취약성 평가 : 타사가 인프라와 구성 요소에 대한 지식이 거의 또는 전혀없이 시스템 취약성 평가
- 외부 침투 테스트 : 시스템에 대한 지식이 거의 또는 전혀없는 타사가 제어된 방식에 따라 능동적으로 시스템 침투를 시도하는 것
- 애플리케이션 및 플랫폼의 내부 그레이/화이트 박스 검ㅌ : 제어의 효율성을 검증하거나 애플리케이션과 플랫폼의 알려진 취약성을 평가하는 것

[보안 모니터링, 알림, 감사 추적 및 사고 대응]
1. 로그 파일 설계 시 고려 사항 : 로그 수집 / 로그 전송 / 로그 스토리지 / 로그 분류 체계 / 로그 분석 및 상곤 관계 / 로그 보호 및 보안
2. 중요 트랜잭션 로그 관리 : 사용자 식별 정보 / 이벤트 유형 / 날짜 및 타임스탬프 / 성공 또는 실패 표시 / 이벤트가 시작된 지점 / 영향을 받은 데이터, 시스템 구성 요소 또는 리소스의 ID 나 이름