보안에 대한 공유 책임모델 원칙
공유 책임 모델
보안에 대한 책임은 AWS와 Customer가 공유하고 있다.
AWS 자체 보안
클라우드 자체 보안 책임
infrastructure를 보호하는 데 책임을 가진다.
- 데이터센터의 물리적인 보안(불이 나거나, 정전발생)
- 하드웨어 소프트웨어 infrastructure
- 데이터센터 자체의 물리적 네트워크(케이블 등)
- 가상화 서비스
- region과 zone 관리
- 초고속 서비스 환경
customer
클라우드 내부에서 제공되는 서비스의 설정에 대한 책임
- OS의 설정,patch, 관리
- 애플리케이션 사용 권한정책, 보안키, 패스워드 설정
- 보안 그룹 설절 및 관리
- 방화벽 설정
- VPC를 통해서 설정(물리적X)
- 계정관리
서비스 별 보안책임
IaaS(자유도 높음/정통 클라우드)
- EC2 가상머신에 MySQL
PaaS
- AWS는 infrastructure 관리, OS 업그레이드 등등
- Customer는 비지니스 로직만 사용하며 코드나 데이터를 관리한다.
- Amazon RDS
SaaS(자유도 낮음/사용자 신경X)
- 해킹 방어
사례
Q1. Oracle upgrades or patches If
the Oracle instance runs as an
Amazon RDS instance?
-> Amazon RDS는 PaaS 형태의 대표적인 사례이며, Amazon RDS를 통해 실행되는 오라클의 업그레이트 및 패치의 책임은 Customer가 아닌 AWS에게 있다.
Q2. Virtualization infrastructure?
virtualization는 데이터센터의 region과 zone에 있기 때문에 책임은 AWS에게 있다.
IAM
IAM 목적
AWS resource에 대한 접근 권한을 관리하기 위함이다.
AWS resource - IAM(Identity and Access Management)은 AWS계정이 상호작용할 수 있도록 하는 구성품 & 서비스이다. ex) EC2, S3
- 어떤 resource에 접근
- 얼마나 resource에 접근
- 어떻게 resource에 접근
- AWS본연의 서비스로 비용이 과금되지 않는다.
IAM의 구성요소
IAM user
인증하 수 있는 사람 or 애플리케이션
IAM user가 접근 권한 부여 및 인증 방식은 두가지로 나뉨
- 타입1. Programmatic access
- 타입2. AWS Management Console access
둘 중에 하나 or 둘 다 사용
IAM group
user들의 모음으로 group별 동일한 권한 부여
IAM policy
어떤 resource에 접근, 어디까지 권한 설정 등이 정리된 문서(정책)/ 그룹 단위로 할당
두가지 타입으로 정책이 나눠짐
-
타입1. Identity-based policies
어떤 IAM user, IAM group, IAM role에 부여하는 정책
하나의 policy -> 여러 entity 가능
하나의 entity -> 여러 policy 가능 -
타입2. Resource-based policies
resource 자체에 권한을 부여하는 정책
기본적으로 권한은 deny를 기본값으로 가지며 명시적으로 allow나 deny로 명시되지 않는 경우는 deny로 간주한다.
IAM role
임시적인 권한(영구적X)/ 특정 위임을 받아 사용한다.
사례)
- IAM policy는 S3 접근권한을 allow하는 policy
- IAM role에 policy를 붙임
- EC2 생성 시 role을 수행할 수 있도록 허용
new AWS account
Account root user
root계정은 막강한 권한을 가지고 있기 때문에 실제 서비스에서 root권한 모두를 사용할 필요가 없음. 보안적으로 사용에 위험이 있기 때문에 직접적으로 사용하지 않는다.
step1. root권한을 중단한다.
- admin(관리자) 기반으로 사용한 IAM user를 만든다.
- IAM group을 만들어 admin기반의 IAM user를 할당한다.
- root user에게 private, public key가 존재하면 폐기한다.
- 신규 생성한 IAM user에게 policy를 부여한다.
step2. MFA를 활성화시킨다.
root user(자기자신)과 신규로 생성한 IAM user 모두 2차 인증을 적용한다.
step3. CloudTrail
계정 차원의 기록을 추적하는 기능으로 선택적으로 사용한다.
step4. root user로써 사용리포트를 활성화한다.
문제
- 공동책임모델에서의 AWS의 책임은?
클라우드의 보안이다.
customer는 클라우드에서의 보안 - 클라우드에서의 보안의 예는?
컴퓨팅 보안 표준 및 규정 준수(AWS)
서비스가 운영되는 시설의 물리적 보안(AWS)
보안 그룹 구성(O)
저장된 데이터 및 전송 중인 데이터 암호화(O)
클로벌 인프라 보호(AWS) - AWS공동 책임 모델에서 AWS의 책임모델은?
타사 애플리케이션 구성
물리적 하드웨어 유지 관리(0)
애플레케이션 액세스 및 데이터보호
사용자 지정 AMI 관리 - 사용자에게 권한을 부여하는 2가지 방법?
프로그래밍 방식 엑세스(DELEVOLP)/ 매니지먼스 콘솔 엑세스(SUPPORT)
아닌것: 기관 액세스, 권한 있는 액세스, 관리자 루트 액세스 - organization사용하면 여러 계정 통합 중앙 관리?
YES - IAM사용하여 계정보호하는 모범 사례?
리소스에 대한 액세스 관리/ 세분화된 액세스 권한 정의
아닌것: 기본 권리 권한을 사용자에게 제공한다.
미사용 및 불필요한 사용자 및 자격 증명을 그대로 둔다
IAM그룹을 사용하여 여러 사용자에게 동일한 액세스 권한을 부여하지 않는다. - 계정 루트 사용자가 수행해야 하는 작업은?
support플랜 변경 작업은 루트 사용자만 수행이 가능하다!!
아닌 것: 애플리케이션에 대한 안전한 액세스,
다른 AWS서비스와 통합
세분화된 권한 변경
위는 IAM으로 가능하다 구지 루트 사용자가 하지 않아도 가능하다. - 최초로그인 후 루투 사용자의 모범 사례는?
계정 루트 액세스 키 삭제 - 시스템 관리자가 사용자의 매니지먼트 콘솔에 로그인 보안 계층을 추가하려면 어떻게해야함?
추가 로그인 보안 계층을 사용자의 AWS 매니지먼트 콘솔에 추가하려면 Multi-factor-authentication을 활성화 - key management service 사용하면 AWS 리소스의 구성을 측정하고 감시하고, 평가할 수 있다.
NO
key management service는 암호화 키를 생성 및 관리하고 다양한 AWS 서비스 및 애플리케이션에서 암호화 사용을 제어할 수 있는 서비스이다.
CloudWatch는 AWS 리소스의 구성을 측정하고 감시하고, 평가할 수 있다
