안녕하세요 !
클라우드 보안 네 번째 정리를 하도록 하겠습니다.
클라우드 보안
* 버킷 정책
AWS S3 버킷 정책은 JSON 형식으로 작성되며, 특정 리소스나 사용자 그룹에 대한 액세스를 허용 또는 거부하는 데 사용됩니다.
1. 액세스 제어 : 버킷 정책을 사용해서 특정 IP 주소, IAM 사용자, IAM 역할, AWS 계정 또는 공개적으로 액세스 가능한 웹 사이트 등의 요소에 대한 액세스를 제어할 수 있습니다.
2. 리디렉션 설정 : 버킷 정책을 사용하여 버킷에 대한 리디렉션 규칙을 설정할 수 있다. 이것은 버킷에 대한 요청을 다른 버킷이나 다른 엔드 포인트로 리디렉션하는데 사용됩니다.
3. 보안 강화 : 버킷 정책을 사용하여 특정 조건에 따라서 액세스를 제한하거나 암호화를 강제할 수 있습니다. 예를 들어 HTTPS 를 강제하거나 특정 규칙에 따라서 버킷에 있는 객체들에 대한 암호화를 요구 할 수 있습니다.
생각해보기 - 어떻게 접근 권한을 제어하면 좋을까 ?
- 퍼블릭 권한
- 정책 : IAM 정책 & 버킷 정책
- 최소 권한의 원칙
* Glacier
- 저렴한 데이터 보관 및 장기 백업
몇 개월, 몇 년 또는 수십 년 동안 데이터를 비용 효율적으로 저장이 가능하다.
- 안전성, 내구성 -> 저렴한 데이터 보관 및 장기 백업이다.
- 복원 시간 : 글라시아는 복원하는데 오래 걸린다.
* ELB
ELB에서 제공하는 관리형 로드 밸런서 서비스 입니다. ELB는 여러 대상 인스턴스 간의 트래픽을 분산하여 네트워크 부하를 균형있게 분산시키는 역할을 합니다. 이것을 통해 애플리케이션의 가용성과 신뢰성을 향상시키고 성능을 최적화 할 수 있습니다.
1. 로드 밸런싱 : ELB는 여러 대상 인스턴스에 대한 트래픽을 분산하여 각 인스턴스의 부하를 균형있게 분산시킨다.
2. 자동 확장 : ELB 는 트래픽이 증가할 때 자동으로 스케일링 되어 처리할 수 있는 인스턴스를 증가시킵니다. 이것은 오토 스케일링과 함께 사용되어 트래픽에 자동으로 인프라를 조정할 수 있습니다.
- 액세스가 적어질 때
서버를 줄여서 비용을 감소한다.
- 액세스가 많아질 때
서버를 늘려서 액세스에 대응한다.
참고로 AWS 는 사용한 만큼 비용을 지불합니다.
1. CLB : 첫 번째로 출시된 로드 밸런서로 L4 및 L7 프로토콜을 지원하며, 여러 포트에 대한 리스닝과 SSL 종단을 지원합니다.
2. ALB : HTTP 및 HTTPS 트래픽을 라우팅하는 L7 로드 밸런서로 여러 대상 그룹에 대한 조건부 라우팅 및 강력한 보안 기능을 제공합니다.
3. NLB : TCP, UDP 및 TLS 트래픽을 처리하는 L4 로드 밸런서로 초당 수백만 개의 요청을 처리할 수 있는 성능과 고정 IP 주소를 제공합니다.
* 오토 스케일링
오토 스케일링은 클라우드 환경에서 자원 확장 또는 축소를 자동으로 관리하는 기능입니다. 주로 서버나 인프라 리소스 수요 변화에 따라서 자동으로 인스턴스를 생성하거나 제거하여 애플리케이션의 성능과 가용성을 유지하는데 사용합니다.
1. 모니터링 : 시스템에서는 리소스 사용률, 트래픽 패턴 등과 같은 여러 지표를 지속적으로 모니터링 합니다.
2. 규칙 정의 : 사용자는 스케일링 동작을 트리거할 조건을 정의 합니다.
3. 동적 조정 : 모니터링 데이터가 규칙과 일치하는 경우, 시스템은 자동으로 필요한 조치를 취합니다.
4. 자동 확장 및 축소 : 필요에 따라 인스턴스를 확장하여 트래픽을 처리하고 트래픽이 줄어들면 인스턴스를 축소하여 비용을 절약합니다.
* 오토 스케일링 정책
오토 스케일링 정책은 자동으로 확장 및 축소를 트리거하는 규칙을 정의하는데 사용됩니다. 이러한 정책은 클라우드 환경에서 인스턴스 수요의 변화에 따라서 올바른 대응을 하기 위해 설정됩니다.
1. 스케일링 아웃 ( 확장 ) 정책 : 트래픽이 증가하거나 자원 사용률이 상승할 때 인스턴스를 자동으로 추가하는 정책입니다.
2. 스케일링 인 ( 축소 ) 정책 : 트래픽이 감소하거나 자원 사용률이 낮아질 때 인스턴스를 자동으로 제거하는 정책입니다.
3. 시간 기반 정책 : 특정 시간대에 트래픽 패턴이 예측 가능한 경우, 해당 시간대에 자동으로 인스턴스를 확장하거나 축소하는 정책입니다. 예를 들어, 주중의 영업 시간 동안에는 인스턴스를 더 많이 확장하고 주말이나 야간에는 인스턴스를 줄일 수 있습니다.
4. 알람 기반 정책 : 모니터링 알람을 기반으로 트리거 되는 정책입니다. 예를 들어 CPU 사용률이 특정 임계값을 초과하면 확장 정책이 트리거 됩니다.
5. 종합적인 정책 : 여러 가지 지표 및 조건을 고려하여 확장 및 축소를 결정하는 종합적인 정책입니다.
* AWS IAM
AWS IAM 역할은 AWS 리소스에 대한 접근을 안전하게 제어하기 위해 사용됩니다. IAM 역할은 특정 작업을 수행할 수 있는 AWS 서비스나 사용자에게 권한을 부여하는데 사용됩니다. 역할은 보안을 강화하고 AWS 리소스에 대한 액세스를 효율적으로 관리하는데 도움이 됩니다.
IAM 에서 user , group, role 만 부여된다.
서비스가 서비스를 건드려도 이럴 때 사용하는 것은 반드시 role 을 사용합니다. role 도 EC2에 위임을 합니다. role 에 부여되어 있는 정책에 허락이 되어있으면 role 에 허용받은 EC2 가 있으면 잠깐 S3 를 건드릴 수 있다.
1. 임시 보안 자격 증명 제공 : IAM 역할을 AWS 리소스에 대한 임시 보안 자격 증명을 생성 할 수 있습니다. 이것은 일시적으로 특정 작업을 수행해야 하는 서비스나 사용자에게 권한을 부여할 때 사용됩니다.
2. 크로스 계정 액세스 : 하나의 AWS 계정에서 다른 계정의 리소스에 접근해야 할 때 IAM 역할을 사용할 수 있다.
3. ROLE : 임시 권한 부여
- USER 의 임시 권한 필요시
- 서비스가 서비스를 액세스 할 때
- 자격 증명 연동
4. 역할에 부여하는 정책
- 권한 정책
- 신뢰 정책
5. 계정 간의 AWS 리소스 접근 다른 리소스 계정을 건드릴 수 없다. DEV 에 있는 유저가 교차 엑세스를 지원하지 않아서 최소 권한 부여 원칙에 맞지 않는 것이다. ROLE 을 사용하는게 더 맞다.
생각해보기 - 권한 부여 권장 가이드
- root 사용 지양 : root 의 액세스 키 및 시크릿 키를 발급하지 않는다.
인라인 : 1회성
관리성 정책 : 템플릿 만들어서 반복 공유 가능
IAM 에서 user , group, role 만 부여된다.
서비스가 서비스를 건드려도 이럴 때 사용하는 것은 반드시 role 을 사용합니다.
role 도 EC2에 위임을 합니다. role 에 부여되어 있는 정책에 허락이 되어있으면 role 에 허용받은 EC2 가 있으면 잠깐 S3 를 건드릴 수 있다.
* 클라우드 워치
AWS 모든 서비스와 연동해서 모니터링 할 수 있는 것.
- 메트릭 모니터링 : 다양한 실시간으로 모니터링 가능하다. cpu, 네트워크 입출력, 디스크 사용률 등과 같은 성능 지표 !
- 경보 및 알람은 임계치가 있는데 80 % 이상이 되면 이메일 sms 알림이 발송된다.
- 자동 조치 : 클라우드 워치는 경보를 기반으로 자동 조치를 수행할 수 있습니다. CPU 사용률이 너무 높으면 해당 인스턴스를 자동으로 확장해서 성능을 향상시킨다.
- 리소스 최적화 가능하다.
* 클라우드 트레일 서비스
AWS 리소스에 대한 활동을 감사 및 모니터링 하는 서비스 입니다. 이 서비스를 사용하면 AWS 계정 내의 모든 API 활동을 기록하고 추적할 수 있습니다. AWS, AWS CLI, SDK 등을 통해 수행된 모든 작업을 추적하므로 보안 감사, 규정 준수, 리소스 변경 추적 등 다양한 목적으로 사용됩니다.
1. 활동 로그 기록 : 클라우드 트레일은 모든 계정 화동을 자동으로 기록합니다.
2. 보안 감사 및 규정 준수 : 클라우드 트레일 로그를 사용하여 보안 감사 및 규정 준수를 수행할 수 있습니다.
3. 리소스 변경 추적 : 클라우드 트레일을 사용하면 리소스 변경 내역을 추적하고 변경된 사항을 기록할 수 있습니다.
4. 다양한 통합 및 분석 : 클라우드 트레일 로그는 아마존 S3 버킷에 저장되므로 다양한 AWS 서비스와 통합되며, 아마존 클라우드 워치 로그 등을 통해 분석하고 모니터링 할 수 있습니다.
* 객체와 버킷
버킷은 윈도의 드라이브와 같은 것이고 객체는 파일과 같은 것이다. 버킷은 폴더가 아니므로 버킷 안에 버킷을 다시 만드는 것은 불가능 합니다. 버킷 안에 버킷을 만들 수 없습니다.
S3 에서는 드라이브를 버킷이라 한다 .
S3 버킷에 대한 액세스 제한을 설정할 수 있다. 제한을 설정하는 방법은 3가지이다. 버킷 단위로 제한하는 버킷 정책, IAM 사용자 단위로 제한하는 사용자 정책, ACL ( 액세스 제어 목록 ) 에 의한 관리 정책이다.
액세스 제한은 리소스, 작업, 효과, 보안 주체에 대해 설정할 수 있다. 즉, '누가, 무엇을, 어떤 것에 대해 가능한가 여부' 를 정하는 기능이다.
S3 정적 웹 사이트를 호스팅할 수 있다.
실습 ) 정적 웹사이트 호스팅 & 버전관리
버킷 만들기를 누릅니다.
버킷을 만듭니다.
객체 인덱스 HTML 을 생성된 것을 확인합니다.
정적 웹 사이트 호스팅 편집에서 활성화로 바꾸어 주고 정적 웹 사이트 호스팅으로 설정합니다.
정적 웹 사이트 호스팅 편집하면 활성화 된다.
그리고 퍼블릭 액세스 차단을 편집에 들어가서 활성화로 바꾸어 줍니다.
Allow 한 상태에서 * 를 눌러줍니다.
json 문법을 붙여넣기 합니다.
여기서 유저 네임에 /* 를 붙입니다.
활성화 된 것을 확인할 수 있습니다.
index.html 버전 활성화의 모습입니다.
액세스 키와 비밀 키를 복사합니다.
끝
'클라우드 보안' 카테고리의 다른 글
클라우드 보안 [다섯 번째 정리] (0) | 2024.03.30 |
---|---|
클라우드 보안 [세 번째 정리] (0) | 2024.03.28 |
클라우드 보안 [두 번째 정리] (0) | 2024.03.27 |
클라우드 보안 [첫 번째 정리] (0) | 2024.03.26 |