aws | aws 클라우드 보안

 

✅ aws 공동 책임 모델

보안과 규정 준수는 AWS와 고객의 공동책임 -> 고객의 운영부담을 덜어주기 위해 만듦

aws : 소프트웨어 가상화 계층부터 aws 서비스가 운영되는 시설의 물리적 보안에 이르기까지 구성요소 운영, 관리 및 제어

고객 : 유휴 데이터와 전송 중 데이터 암호화할 책임. 네트워크에 보안 구성하고 보안 자격 증명 및 로그인 안전하게 관리

 

 

✅ aws의 책임 - 클라우드의 보안

• 데이터 센터의 물리적 보안 - 필요 기반의 제어된 액세스
• 하드웨어 및 소프트웨어 인프라 - 스토리지 폐기, 호스트 엑세스 로깅 및 감사
• 네트워크 인프라 - 침입 탐지
• 가상화 인프라 - 인스턴스 격리

 

✅ 고객의 책임 - 클라우드에서의 보안

• aws 서비스를 사용하여 구현한 것과 aws에 연결되는 어플리케이션에 대한 책임이 있음. 고객 콘텐츠는 모두 고객이 제어
• aws에 저장하기로 선택한 콘텐츠
• 콘텐츠에 사용되는 aws 서비스
• 콘텐츠가 저장되는 국가
• 콘텐츠의 형식 및 구조와 마스킹, 익명화 또는 암호화 여부
• 콘텐츠에 액세스 할 수 있는 사용자 및 액세스 권한을 부여, 관리, 취소하는 방법

 

 

✅ 서비스 특성 및 보안 책임

✔ IaaS(서비스형 인프라)

• 고객은 네트워킹 및 스토리지 설정을 보다 유연하게 구성 가능
• 보안의 더 많은 측면을 고객이 관리해야함
• 액세스 제어를 고객이 구성
• 고객은 필요한 보안 구성 및 관리 작업을 수행할 책임이 있음
• ex. 게스트 OS 업데이트 및 보안 패치, 방화벽, 보안 그룹 굿ㅇ

-> amazon ec2 같은 서비스는 IaaS 범주에 포함. 모든 보안 구성과 관리 작업을 고객이 수행

 

✔ PaaS(서비스형 플랫폼)

• 고객이 기본 인프라를 관리할 필요가 없음
• 운영 체제, 데이터베이스 패치 적용, 방화벽 구성 및 재해 복구를 aws가 처리
• 고객은 코드 또는 데이터 관리에 집중 가능
• 어플리케이션 배포 및 관리에만 전적 집중 가능.
• 리소스 조달, 용량 계획, 소프트웨어 유지관리 또는 패치 걱정할 필요 없음

-> lambda, RDS 같은 서비스 : 인프라 계층, 운영 체제 및 플랫폼을 aws가 운영. 고객은 엔드포인트에 액세스하여 데이터 저장하고 검색하기만 하면 됨

✔ SaaS(서비스형 소프트웨어)

• 소프트웨어가 중앙에서 호스팅
• 구독 모델 또는 종량 과금제로 라이선스 부여
• 웹, 모바일 앱, 또는 API 통해 서비스에 액세스
• 고객은 서비스를 지원하는 인프라를 관리할 필요가 없음

ex.

AWS trudted advisor : AWS 환경 분석 후 모범 사례에 따라 리소스 프로비저닝하는데 유용한 실시간 지침과 권장사항 제공

AWS Shield : AWS에서 실행되는 어플리케이션을 보호하는 관리형 DDos 방어 서비스

Amazon Chime : 단일 어플리케이션에서 조직 내/외부의 회의, 채팅 및 비즈니스 통화 기능을 사용할 수 있는 커뮤니케이션 서비스. 종량 과금제 커뮤니케이션 서비스

 

✅ 다음 배포에서 책임은 누구에게 있습니까?

 

 

 

 

✅ EC2 인스턴스의 운영 체제에 대한 업그레이드 및 패치

 

 

데이터 센터의 물리적 보안

가상화 인프라 

EC2 보안그룹 설정

EC2 인스턴스에서 실행되는 어플리케이션의 구성

Oracle 인스턴스가 Amazon RDS 인스턴스로 실행되는 경우 Oracle 업그레이드 또는 패치

Oracle EC2 인스턴스에서 실행되는 경우 Oracle 업그레이드 또는 패치

S3 버킷 액세스 구성

 

 

✅ AWS Management Console에 대한 해킹 차단

• 서브넷 구성
• VPC 구성
• AWS 리전의 네트워크 중단에 대한 보호
• SSH 키 보안
• AWS 고객 데이터 간의 네트워크 격리 보장
• 웹 서버와 S3 버킷 간의 지연 시간이 짧은 네트워크 연결
• 모든 사용자 로그인에 대해 Multi-Factor Authentication 적용

 

 

✅ AWS Identity and access management(IAM)

IAM을 사용하여 AWS 리소스에 대한 액세스 관리

- 리소스는 사용자가 작업을 수행할 수 있는 AWS 계정의 엔터티

ex. ec2 instance, s3 버킷

AWS 계정의 리소스를 시작, 구성, 관리 및 종료하는데 필요한 액세스 권한을중앙에서 관리하는 도구

각 서비스에서 사용자가 호출할 수 API 호출을정확히 지정

 

 

 

✅ IAM 필수 구성 요소

• IAM 사용자
• IAM 그룹
• IAM 정책 : 액세스 가능한 리소스와 각 리소스에 대한 액세스 수준 정의
• IAM 역할 : AWS 서비스 요청을 위한 권한 세트 부여

 

 

✅ IAM 액세스 유형 선택

• 프로그래밍 방식 액세스
  • 액세스 키 ID / 보안 액세스 키
• aws cli 및 sdk 액세스 제공
  • aws management console 액세스
  • 12자리 계정 ID 또는 별칭 / IAM 사용자 이름 / IAM 암호
  • -> 활성화 시 MFA 에 의해 인증코드 입력하라는 메시지 표시

 

 

✅ IAM MFA => 보안 향상 위해

• 사용자 및 시스템은 일반 로그인 자격증명에 더해 MFA 토큰을 제공해야 AWS 서비스 및 리소스에 액세스 가능
  MFA 인증 토큰 생성에 사용할 수 있는 옵션
  가상 MFA 호환 애플리케이션(예: Google Authenticator 또는Authy 2-Factor Authentication)
• U2F 보안키 디바이스 및 하드웨어 MFA 디바이스

 

 

 

✅ 권한 부여

 

 

사용자, 서비스 또는 어플리케이션에 부여해야하는 권한을 겨정하는 프로세스

IAM 사용자에겐 aws 계정의 리소스나 데이터에 엑세스 할 수 있는 권한 없음

대신 JSON 형식의 문서인 정책 생성하여 명시적으로 부여

 

 

✅ IAM : 권한 부여

권한 할당하여면 IAM 정책을 생성하거나 계정의 기존 정책을 찾아야함. 기본 권한 없음

최소 권한의 원칙! 

IAM 서비스 구성 범위는 글로벌 , 설정은 AWS 리전 수준에서 정의 되지 않음

 

 

 

 

✅ IAM 정책 - 권한을 정의하는 문서

 

1. 자격 증명 기반 정책

• 관리형 정책 : AWS 계정의 여러 사용자, 그룹 및 역할에 연결가능한 독립 실행형 자격 증명 기반 정책
• 인라인 정책 : 사용자가 생성하고 관리하며, 단일 사용자 그룹 또는 역할에 직접 포함

2. 리소스 기반 정책 

• s3 버킷 과 같은 리소스에 연결하는 JSON 정책 문서. 보안 주체가 해당 리소스에 대해 수행할 수 있는 작업 및 관련 조건 제어

 

 

예제

▶ 다음 리소스에 대한 액세스 권한만 부여

table-name 으로 표시되는 DynamoDB 테이블

버킷 이름이 bucket-name 으로 표시되는 AWS 계정의 s3 버킷과 버킷에 포함된 모든 객체

 

NotResource요소가 있는 경우 사용자는 정책에 지정된 작업 및 리소스를 제외한 다른 DynamoDB또는 S3 작업 또는 리소스를 사용할 수 없음.

다른 정책에서 권한이 부여된 경우에도 마찬가지

명시적 거부문>>허용문 보다 우선 적용

 

 

 

✅ 리소스 기반 정책

 

• 리소스에 액세스할 수 있는 사용자와 해당 사용자가 수행할 수 있는 작업 지정
• 인라인 전용 정책이며 관리형은 없음
• 일부 AWS 서비스만 지원

 

 

 

✅ IAM 권한 -> 사용자, 그룹 및 역할에 부여되는 권한 세부적 조정 가능

 

 

권한 허용 여부 결정 시

1. 명시적 거부 정책이 있는가

.2. 명시적 허용 정책 있는가

=> 명시적 거부나 허용 정책이 없는 경우 IAM은 기본값으로->기본값은 액세스를 거부하는 것 => 암시적 거부

 

 

 

✅ IAM 그룹 : 사용자 모음의 권한 지정

• 그룹은 여러사용자 포함가능, 사용자는 여러 그룹에 속할 수 있음
• 그룹은 중첩될 수 없음. 오직 사용자만 포함할 수 있으며 그룹 포함안됨
• aws 계정의 모든 사용자를 자동으로 포함하는 기본 그룹은 없음

 

 

✅ IAM 역할

특정 권한이 있는 계정에 생성할 수 있는 IAM 자격 증명

IAM 사용자와 유사 - 권한 정책을 IAM 역할에 연결

IAM 사용자와 다른점

• 한 사람에게 고유하게 연결되지 않음
• 개인, 어필리케이션 또는 서비스가 역할 수임가능

역할은 임시 보안 자격 증명 제공

 

 

 

✅ IAM 역할 사용 예

 

시나리오

EC2 인스턴스에서 실행되는 어플리케이션에 S3버킷에 대한 액세스 권한 필요

(EC2 인스턴스에서 photos 라는 s3 버킷에 엑세스해야하는 어플리케이션 실행)

 

sol

S3 버킷에 대한 액세스 권한 부여하는 IAM 정책 정의

정책을 역할에 연결

EC2 인스턴스가 역할을 수임하는 것을 허용

관리자는 IAM 역할 생성하고 EC2 인스턴스에 연결

이때, IAM 역할에는 지정된 S3 버킷에 대한 읽기 전용 액세스 권한을 부여하는 권한 정책 포함 + EC2 인스턴스가 해당 역할 수임하고 임시 자격 증명을 가져오도록 허용하는 신뢰 정책 포함)

어플리케이션 인스턴스에서 실행 시 역할의 임시 자격 증명을 사용해 photos 버킷에 액세스 가능

어플리케이션 개발자 권한을 부여하지 않아도 photos 버킷에 엑세스 가능. 개발자는 자격증명을 공유하거나 관리할 필요 없음

 

 

✅ AWS 계정 루트 사용자 vs IAM 액세스

 

계정의 모든 리소스에 대한 모든 액세스 권한 보유

최소 권한의 원칙에 따라 IAM 사용하여 추가 사용자 생성하고, 이러한 사용자에게 권한 할당하는 것이 좋음