요구사항 정리 및 미팅을 진행 했다.
미팅 후 팀원들과 모여서 미팅 내용을 정리하고 그에 맞는 일정을 만들었다.
오늘 내가 담당해서 조사하는 내용은 어제 했던 security hub다.
더 깊은 조사가 필요하다.
[1단계 : 원본 데이터]VPC, CloudTrail, S3 등을 사용 중이라면 별도 설정이 불필요하며, Inspector 경우는 IAM, VPC Endpoint, SSM Agent 설치 등 별도 조치가 필요합니다.
[2단계 : 탐지]GuardDuty, Inspector, Macie는 Region별 활성화하면 탐지(Findings)합니다.
[3단계 : 통합]Region별 활성화하면 각 서비스에서 탐지한 결과가 통합됩니다.Region별 탐지 결과를 하나의 Region으로 통합할수도 있습니다.탐지된 결과 중 심각도에 따라 내부 규정에 위배되는 항목들은 조치를 취합니다. (ex : 비밀번호 변경 90일 기한 등)탐지된 결과 중 침해사고가 의심되는 부분은 Detective(4단계 분석)으로 이동하여 상세한 분석을 진행합니다.
[4단계 : 분석]Region별 활성화만 하면 각 서비스에서 탐지한 결과에 대해 보안 활동 그래프 형태로 자료를 제공합니다.
침해사고가 의심되는 Findings는 분석하여 오탐인지 침해사고인지 판단하고, 침해사고인 경우 즉시 조치를 취합니다.
[5단계 : 대응]Findings를 EventBridge Rule 설정하여 자동화합니다. (ex : SNS 통보, Lambda 통해 자동 처리 등)
Amazon DynamoDB 복구 활성화 로그 > aws config 의 탐지 > Security Hub 결과 확인
https://sjramblings.io/security-hub-now-supports-custom-aws-config-rules
DynamoDB를 복구하는 과정에서 탐지와 결과를 확인 하는 방법을 블로깅 해둔 자료다.
https://www.playingaws.com/posts/aws-security-hub-deep-dive/
security hub에서는 다른 aws서비스들과 통합해서 로그를 보여준다.
Security Hub 실습
https://catalog.workshops.aws/security-hub/en-US/0-workshop-introduction


참고할 만한 아키텍처를 뽑았다.
security hub는 config가 꼭 필요하다고 생각을 하고 있었지만 아니다.
config의 규칙들이 필요할 뿐 자기 혼자서 보안검사도 진행하고 스스로 하는 일들이 많았다.
하지만 실시간 검사를 위해서는 트리거가 필요한 것 같은데 config가 그 역할을 하는게 아닌가 하는 생각이 든다.
아키텍처를 직접 구현하지는 않아서 구현 후 확인이 필요한 부분이다.
👉 데이터소스로 Cloudwatch, AMP 비교 조사
1. 메트릭
CloudWatch
- 사용자 정의 애플리케이션(컨테이너) 지표
단점
- 태스크 수준 지표를 원하는 경우 CloudWatch Container Insights를 추가로 사용해야 함
AMP
- 사용자 정의 애플리케이션(컨테이너) 지표
- 태스크 수준 CPU, 메모리, 네트워크 및 스토리지 지표
장점
- 추가 구성 없이 태스크 및 컨테이너 지표 생성 가능
2. 알림
CloudWatch
- Metric을 기준으로 CloudWatch Alarm을 생성하고 Alarm을 SNS와 연결
장점
- AWS에서 제공하는 기능만으로 연결 가능
단점
- 3개의 관리 포인트 (Metric, Alarm, SNS) 가 존재
AMP
- 프로메테우스 알림 관리자(Alert Manager)를 사용하여 SNS와 연결
장점
- 알림을 SNS와 직접 연결할 수 있음
단점
- 프로메테우스 알림 구성 yaml 파일을 직접 작성해야 함
https://docs.aws.amazon.com/ko_kr/prometheus/latest/userguide/AMP-alertmanager-config.html
3. 비용
CloudWatch
https://aws.amazon.com/ko/cloudwatch/pricing/
AMP
https://aws.amazon.com/ko/prometheus/pricing/
4. AMP 아키텍처
👉 CCE, CVE 조사
CCE (Common Configuration Enumeration)
CCE 목록이란?
- 사용자의 취약한 설정에 따라 발생하는 정보시스템 취약점으로 시간이 많이 소요되고, 시스템에 대한 영향도 분석 및 각 시스템에 대한 조치 방법 등을 충분히 숙지해야 평가 대응 및 조치가 가능
- 여러 소스와 툴 간의 구성 데이터의 명확하고 빠른 상관관계를 촉진해 작업 흐름을 개선하기 위해 보안 관련 시스템 구성 문제에 붙인 고유 식별 체계
- CCE 식별자를 활용해 구성 평가 도구 검사를 구성 모범 사례와 연결지을 수 있음
- 여러 소스의 정보를 처리할 때 일관된 식별자를 사용하면 데이터 상관 관계를 개선, 상호 운용성 활성화, 자동화를 촉진하며, 상황 인식 및 IT 보안 감사 및 규정 준수에 사용할 메트릭 수집을 용이하게함 (CVE®( Common Vulnerabilities and Exposures ) 또한 정보 보안 취약성에 대해 동일한 기능 제공)
- CVE와 유사하게 CCE는 특정 보안 관련 구성 문제에 고유한 공통 식별자를 할당
- CCE-ID는 구성 감사 도구와 같은 기계 판독 가능 또는 실행 가능 기능 사이의 가교 역할 수행
- 현재 CCE는 소프트웨어 기반 구성에만 초점을 맞추고 있으며 하드웨어 및/또는 물리적 구성에 대한 권장 사항은 지원되지 않음
- NIST는 자신의 제품의 구성 식별을 사용하도록 CCE를 요청하는 벤더사를 지원
[CCE 목록](https://ncp.nist.gov/cce)
예시
구성 형태
- CCE 식별 번호 : "CCE-2715-1"
- 설명 : 구성 문제에 대한 사람이 이해할 수 있는 설명
- 개념 매개변수 : 시스템에서 CCE를 구현하기 위해 지정해야 하는 매개변수
- 관련 기술 메커니즘 : 주어진 구성 문제에 대해 원하는 결과를 구현하는 하나 이상의 방법이 있을 수 있음
- 참조 : 구성 문제가 자세히 설명된 문서 또는 도구의 특정 섹션에 대한 포인터
CVE (Common Vulnerabilities and Exposure)
[CVE](https://www.cve.org/About/Overview)
- OS, application 설계상의 고유 취약점(악용될 수 있는 약점으로 인해 발생하는 소프트웨어, 펌웨어, 하드웨어 또는 서비스 구성 요소의 결함으로 영향을 받는 구성 요소의 기밀성, 무결성 또는 가용성에 부정적인 영향을 미침)
- CVE는 취약점을 식별, 정의 및 분류하며 카탈로그의 각 취약점에 대해 하나의 CVE 레코드가 존재
- 취약점은 발견된 후 CVE 프로그램과 파트너 관계를 맺은 전 세계의 조직에서 할당하고 게시하며 파트너는 취약점에 대한 일관된 설명을 전달하기 위해 CVE 레코드를 게시
- 정보 기술 및 사이버 보안 전문가는 CVE 레코드를 사용하여 동일한 문제를 논의하고 취약점의 우선 순위를 지정하고 해결하기 위한 노력 수행
(ex) 하트블리드 취약점(cve-2014-0160), 쉘쇼크 취약점(CVE-2014-6271) 등
[CVE 목록](https://cve.mitre.org/data/downloads/allitems.html)
예시
AWS 서비스에서 CCE 및 CVE를 점검하는 방법
1) S3
모든 Amazon S3 버킷 식별 및 감사
IT 자산의 식별은 거버넌스 및 보안의 중요한 측면으로, 보안 상태를 평가하고 잠재적인 취약 영역에 조치를 취하려면 모든 Amazon S3 리소스에 대한 가시성을 확보해야 함.
- Tag Editor를 사용하여 보안에 민감하거나 감사에 민감한 리소스를 식별하고 태그를 지정한 다음 이러한 리소스를 검색해야 할 때 해당 태그를 사용할 것(자세한 내용은 (https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) 참조%C2%A0%EC%B0%B8%EC%A1%B0))
- S3 Inventory를 사용하여 비즈니스, 규정 준수 및 규제 요구 사항에 대한 객체의 복제 및 암호화 상태를 감사하고 보고 (자세한 내용은 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-inventory.html) 참조%C2%A0%EC%B0%B8%EC%A1%B0))
- Amazon S3 리소스에 대한 리소스 그룹을 생성 (자세한 내용은 (https://docs.aws.amazon.com/ARG/latest/userguide/welcome.html) 참조)
AWS 모니터링 도구를 사용하여 모니터링 구현
- 모니터링
모니터링은 Amazon S3 및 AWS 솔루션의 안정성, 보안, 가용성 및 성능을 유지하는 데 중요한 부분으로 AWS는 Amazon S3 및 기타 AWS 서비스를 모니터링하는 데 도움이 되는 몇 가지 도구와 서비스를 제공
(ex) Amazon S3에 대한 Amazon CloudWatch 지표 (PutRequests, GetRequests, 4xxErrors, DeleteRequests 등) (자세한 내용은 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudwatch-monitoring.html) 및 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html) 단원을 참조)
Amazon S3 서버 액세스 로깅 활성화
- 서버 액세스 로깅은 버킷에 대한 요청에 대한 자세한 기록을 제공
- 서버 액세스 로그는 보안 및 액세스 감사를 지원하고, 고객 기반에 대해 알아보고, Amazon S3 청구서를 이해하는 데 도움이 될 수 있음
- 서버 액세스 로깅 활성화에 대한 지시사항은 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html) 참조%C2%A0%EC%B0%B8%EC%A1%B0)
- 또한 s3-bucket-logging-enabled](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-logging-enabled.html) AWS%C2%A0AWS) Config 관리형 규칙을 사용하여 지속적인 탐지 제어를 구현하는 것도 고려
AWS CloudTrail 사용
- AWS CloudTrail은 Amazon S3에서 사용자, 역할 또는 AWS 서비스가 수행한 작업 기록을 제공 CloudTrail에서 수집한 정보를 사용하여 다음을 결정 가능
- Amazon S3에 대한 요청
- 요청이 이루어진 IP 주소
- 요청한 사람
- 요청이 이루어진 시기
- 요청에 대한 추가 세부정보
- cloudtrail-s3-dataevents-enabledAWS Config 는 하나 이상의 CloudTrail 추적이 S3 버킷에 대한 데이터 이벤트를 로깅하고 있는지 확인하는 데 사용할 수 있는 관리형 규칙을 제공함(자세한 내용은 AWS Config Developer Guide 의 (https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-s3-dataevents-enabled.html) 참조%C2%A0%EC%B0%B8%EC%A1%B0))
AWS config 활성화
- AWS Config는 AWS 리소스의 구성을 평가, 감사 및 평가하는 데 도움이 됨
- AWS Config는 원하는 보안 구성에 대해 기록된 구성을 평가할 수 있도록 리소스 구성을 모니터링 AWS Config를 사용하여 다음을 수행 가능
- AWS 리소스 간의 구성 및 관계 변경 사항 검토
- 자세한 리소스 구성 기록 조사
- 내부 지침에 지정된 구성에 대한 전반적인 규정 준수 여부 확인
- AWS Config를 사용하면 규정 준수 감사, 보안 분석, 변경 관리 및 운영 문제 해결을 간소화 가능 (자세한 내용은 AWS Config Developer Guide 의 (https://docs.aws.amazon.com/config/latest/developerguide/gs-console.html)참조%EC%B0%B8%EC%A1%B0))
- AWS Config 사용 방법의 예는 (https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/)
Amazon Macie를 사용하여 민감한 데이터 검색
- Amazon Macie는 기계 학습 및 패턴 매칭을 사용하여 민감한 데이터를 검색하는 보안 서비스
- Macie는 데이터 보안 위험에 대한 가시성을 제공하고 이러한 위험에 대한 자동화된 보호를 활성화하므로, Macie를 사용하면 Amazon S3 데이터 자산에서 민감한 데이터의 검색 및 보고를 자동화하여 조직이 Amazon S3에 저장하는 데이터를 더 잘 이해 가능
- Macie로 중요한 데이터를 탐지하려면 많은 국가 및 지역에서 점점 더 많은 중요한 데이터 유형 목록을 탐지하도록 설계된 기본 제공 기준 및 기술을 사용 가능
- 이러한 중요한 데이터 유형에는 여러 유형의 개인 식별 정보(PII), 금융 데이터 및 자격 증명 데이터가 포함됨 또한 일치시킬 텍스트 패턴을 정의하는 정규식과 선택적으로 결과를 구체화하는 문자 시퀀스 및 근접 규칙을 정의하는 사용자 정의 기준을 사용할 수도 있음
- Macie가 S3 객체에서 민감한 데이터를 감지하면 Macie는 보안 결과를 생성하여 알려줌
- 이 조사 결과는 영향을 받는 개체, Macie가 찾은 중요한 데이터의 유형 및 발생 횟수, 영향을 받는 S3 버킷 및 개체를 조사하는 데 도움이 되는 추가 세부 정보에 대한 정보를 제공 (자세한 내용은 (https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html) 참조%C2%A0%EC%B0%B8%EC%A1%B0))
S3 스토리지 렌즈 사용
- S3 Storage Lens는 객체 스토리지 사용 및 활동에 대한 조직 전체의 가시성을 확보하는 데 사용할 수 있는 클라우드 스토리지 분석 기능으로, S3 Storage Lens는 또한 메트릭을 분석하여 스토리지 비용을 최적화하고 데이터 보호를 위한 모범 사례를 적용하는 데 사용할 수 있는 상황별 권장 사항을 제공
- S3 Storage Lens를 사용하면 메트릭을 사용하여 조직 전체에 얼마나 많은 스토리지가 있는지 또는 가장 빠르게 성장하는 버킷 및 접두사를 찾는 것과 같은 요약 통찰력을 생성 가능
- 또한 S3 Storage Lens 지표를 사용하여 비용 최적화 기회를 식별하고, 데이터 보호 및 액세스 관리 모범 사례를 구현하고, 애플리케이션 워크로드의 성능을 개선 가능
- 예를 들어 S3 수명 주기 규칙이 없는 버킷을 식별하여 7일이 지난 불완전한 멀티파트 업로드를 중단 가능하며, S3 복제 또는 S3 버전 관리와 같은 데이터 보호 모범 사례를 따르지 않는 버킷을 식별할 수도 있음 (자세한 내용은(https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens_basics_metrics_recommendations.html) 참조%C2%A0%EC%B0%B8%EC%A1%B0))
AWS 보안 권고 모니터링
- AWS 계정에 대한 Trusted Advisor에 게시된 보안 권고를 정기적으로 확인하는 것이 권장 (특히 "오픈 액세스 권한"이 있는 Amazon S3 버킷은 (https://docs.aws.amazon.com/cli/latest/reference/support/describe-trusted-advisor-checks.html) 사용하여%C2%A0%EC%82%AC%EC%9A%A9%ED%95%98%EC%97%AC) 프로그래밍 방식으로 작업 수행 가능)
2) Lambda
[Lambda]
- Amazon Inspector를 사용하여 Lambda 함수 및 계층의 보안 취약성을 탐지 가능
- Amazon Inspector는 취약성 인텔리전스 데이터베이스를 기반으로 취약점을 발견하고 보고하는 자동화된 취약성 검색 서비스
- Amazon Inspector 취약성 인텔리전스 데이터베이스는 내부 AWS 보안 연구 팀, 유료 공급업체 피드 및 업계 표준 보안 권고로부터 데이터를 수집
- Amazon Inspector는 활성 Lambda 함수 및 계층의 인벤토리를 자동으로 생성한 다음 소프트웨어 패키지 취약성을 지속적으로 모니터링
- Amazon Inspector는 취약성을 발견하면 보안 문제에 대한 세부 정보 및 문제 해결 방법이 포함된 결과를 생성
- Amazon Inspector 콘솔에서 Amazon Inspector 결과를 보거나 다른 AWS 서비스를 통해 결과를 처리 가능
- Amazon Inspector Lambda 스캔을 활성화하고 구성하는 방법에 대한 자세한 내용은 Amazon Inspector를 (https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html)을%EC%9D%84) 참조
3) EC2
AWS에서 제공하는 규정 준수를 지원하는 리소스
- 보안 및 규정 준수 빠른 시작 안내서 – 이 배포 안내서에서는 아키텍처 고려 사항에 대해 설명하고 보안 및 규정 준수에 중점을 둔 기본 AWS 환경을 배포하기 위한 단계를 제공
- Amazon Web Services에서 HIPAA 보안 및 규정 준수 기술 백서 설계 - 이 백서는 기업에서 AWS를 사용하여 HIPAA를 준수하는 애플리케이션을 만드는 방법을 설명 (모든 AWS 서비스에 HIPAA 자격이 있는 것은 아니므로 자세한 내용은 HIPAA 적격 서비스 참조를 참조)
- AWS 규정 준수 리소스 - 고객 조직이 속한 산업 및 위치에 적용될 수 있는 워크북 및 가이드 콜렉션
- AWS Config 개발자 안내서의 규칙을 사용하여 리소스 평가 – AWS Config 서비스는 내부 사례, 산업 지침 및 규제에 대한 리소스 구성의 준수 상태를 평가
- AWS Security Hub – 이 AWS 서비스는 AWS 내의 보안 상태에 대한 포괄적인 보기를 제공함. Security Hub는 보안 제어를 사용하여 AWS 리소스를 평가하고 보안 업계 표준 및 모범 사례에 대한 규정 준수를 확인 (지원되는 서비스 및 제어 목록은 Security Hub 제어 참조를 참조)
- AWS Audit Manager - 이 AWS 서비스는 AWS 사용을 지속해서 감사하여 위험을 관리하고 규정 및 업계 표준을 준수하는 방법을 간소화할 수 있도록 지원
4) RDS
- AWS Security Hub는 보안 제어를 사용하여 리소스 구성 및 보안 표준을 평가하여 다양한 규정 준수 프레임워크를 준수할 수 있도록 지원함
- Security Hub를 사용하여 RDS 리소스를 평가하는 방법에 대한 자세한 내용은 AWS Security Hub 사용 설명서의 (https://docs.aws.amazon.com/securityhub/latest/userguide/rds-controls.html)를%EB%A5%BC) 참조
- Security Hub를 사용하여 보안 모범 사례와 관련된 RDS의 사용량을 모니터링 가능 (자세한 내용은 (https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)를%EB%A5%BC) 참조)
👉 Tag Editor, Resource Group, System Manager 조사
리소스 그룹
많은 리소스에 대한 태스크를 한 번에 관리하고 자동화 가능하다.
대량으로 리소스를 사용하는 경우 관리하기 편하도록 사용
- 태그 기반💡 개인 식별 정보(PII)나 기타 기밀 정보 또는 민감한 정보를 태그에 저장하지 마십시오. 태그 기반 리소스 그룹은 리소스 유형 및 태그 목록을 지정하는 쿼리를 기반으로 멤버십을 구성. 태그는 조직 내에서 리소스를 식별하고 분류하는 데 도움이 되는 키이다. 태그에 키 값을 포함시킬 수도 있다.
- AWS CloudFormation 스택 기반 AWS CloudFormation스택 기반 리소스 그룹은 현재 지역의 계정에 있는 AWS CloudFormation 스택을 지정하는 쿼리를 기반으로 멤버십을 구성. 그룹 에 있고 싶은 리소스 유형 을 선택할 수 있다. 쿼리를 하나의 AWS CloudFormation 스택에만 기반할 수 있다.
AWS Resource Groups및 권한
Resource Groups 기능 권한은 계정 수준이다. 계정을 공유하는 IAM 주체 (예: 역할 및 사용자) 가 올바른 IAM 권한을 가지고 있으면 사용자가 생성한 리소스 그룹과 함께 작업할 수 있다.
AWS Resource Groups으로 작업하는 AWS 서비스
AWS 서비스
[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/)—](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/)%E2%80%94) 스택 템플릿을 AWS CloudFormation 사용하여 리소스 그룹을 생성.
[CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)—](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)%E2%80%94) 를 사용하여 모든 리소스 그룹 작업을 AWS CloudTrail 캡처.
[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) —](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)%C2%A0%E2%80%94) AWS 리소스와 에서 실행하는 애플리케이션을 실시간으로 모니터링할 수 AWS 있다.
[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)—](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)%E2%80%94) AWS 리소스를 파악하고 제어 가능.
[Amazon VPC Resource Groups](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/) —](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/)%C2%A0%E2%80%94) 리소스에 대한 원치 않는 네트워크 액세스를 식별
Resource Groups와 함께
AWS리소스 공급 및 구성을 동시에 수행할 수 있습니다. 태그별로 리소스를 정리하세요. 다른 스택의 리소스를 정리하세요. Amazon을 사용하여 리소스 그룹의 AWS 리소스에 대한 통찰력을 CloudWatch 수집하거나 를 사용하여 운영 조치를 AWS Systems Manager 취하십시오.
작업을 수행한 사람 (역할, 사용자 또는 역할 등의 IAM 주체), 작업이 수행된 시간, 작업이 발생한 위치 (소스 IP 주소AWS 서비스) 등과 같은 세부 정보를 포함하여 리소스 그룹에서 수행된 작업에 대한 정보를 캡처. 그런 다음 이러한 기록을 분석에 사용하거나 후속 조치를 트리거하는 데 사용할 수 있다.
단일 Resource Groups를 사용하여 단일 Resource Groups의 지표 및 경보를 표시합니다.
운영 통찰력을 수집하고 리소스 그룹을 기반으로 애플리케이션에 대한 대량 조치를 취하세요. AWS Systems Manager콘솔에서 Application Manager 사용자 지정 애플리케이션 페이지는 리소스 그룹을 기반으로 하는 애플리케이션의 작업 데이터를 자동으로 가져와서 표시합니다. ApplicPrivate P에서 어떤 리소스가 호환되고 올바르게 작동하고 있는지, 어떤 리소스에 작업이 필요한지에 대한 정보를 사용할 수 있습니다.
AWS Resource Groups 을 사용하여 네트워크 액세스 요구 사항에 맞는 소스 및 대상을 지정할 수 있습니다. 이렇게 하면 네트워크 구성 방식에 관계없이 AWS 환경 전반에서 네트워크 액세스를 제어할 수 있습니다.
출처 - https://docs.aws.amazon.com/ko_kr/ARG/latest/userguide/resource-groups.html, https://docs.aws.amazon.com/ko_kr/ARG/latest/userguide/integrated-services-list.html
CloudFormation
AWS CloudFormation은 AWS 리소스를 모델링하고 설정하여 해당 리소스를 관리하는 시간을 줄이고 AWS에서 실행되는 애플리케이션에 더 많은 시간을 할애할 수 있도록 도와주는 서비스
CloudFormation의 이점
- 인프라 관리 간소화 백엔드 데이터베이스도 포함하는 확장 가능한 웹 애플리케이션의 경우 Auto Scaling 그룹, Elastic Load Balancing 로드 밸런서 및 Amazon Relational Database Service 데이터베이스 인스턴스를 사용할 수 있습니다. 각 개별 서비스를 사용하여 이러한 리소스를 프로비저닝할 수 있으며 리소스를 생성한 후 함께 작동하도록 구성해야 한다. 이러한 모든 작업은 애플리케이션을 시작하고 실행하기도 전에 복잡성과 시간을 추가할 수 있다.
- 인프라를 신속하게 복제 애플리케이션에 추가 가용성이 필요한 경우 한 지역을 사용할 수 없게 되더라도 사용자가 다른 지역에서 애플리케이션을 계속 사용할 수 있도록 여러 지역에 복제할 수 있다.
- 인프라에 대한 변경 사항을 쉽게 제어 및 추적 경우에 따라 점진적으로 업그레이드하려는 기본 리소스가 있을 수 있다. 예를 들어 Auto Scaling 그룹의 최대 인스턴스 수를 줄이기 위해 Auto Scaling 시작 구성에서 더 높은 성능의 인스턴스 유형으로 변경할 수 있다. 업데이트를 완료한 후 문제가 발생하면 인프라를 원래 설정으로 롤백해야 할 수 있다.
출처 - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html
AWS리소스에 태그를 추가하는 방법
AWS리소스에 태그를 추가하는 세 가지 방법이 있다.
- AWS 서비스API 작업
- 태그 편집기 콘솔
- Resource Groups 태깅 API
출처 - https://docs.aws.amazon.com/ko_kr/tag-editor/latest/userguide/tagging.html
AWS Systems Manager
태그를 지정할 수 있는 Systems Manager 리소스
- Associations
- 자동화
- Documents
- 유지 관리 기간
- 관리형 노드
- EC2 인스턴스는 Linux 인스턴스용 Amazon EC2 사용 설명서의 [Amazon EC2 리소스 태그](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) 섹션을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)%C2%A0%EC%84%B9%EC%85%98%EC%9D%84) 참조하세요. (콘텐츠는 Linux와 Windows용 EC2 인스턴스에 모두 적용됨)
- 온프레미스 서버 및 VM의 경우[하이브리드 환경을 위한 관리형 노드 활성화 생성](https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/sysman-managed-instance-activation.html)을](https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/sysman-managed-instance-activation.html)%EC%9D%84) 참조하세요.
- OpsItems
- OpsMetadata
- 파라미터
- 패치 기준
자동 태깅
👉 Guard Duty (지능형 위협 탐지 서비스)
머신 러닝 기반으로 보안 위협을 탐지하여 방대한 양의 로그 데이터 속에서 신속하게 위협을 탐지할 수 있도록 도와줍니다.
Guard Duty 장점
- 관리형 위협 탐지 서비스
- 아키텍쳐 변경이나 성능 저하 없이 손쉽게 원클릭 활성화
- No Agent, No Sensor
- AWS 계정 및 리소스에 대한 상시 모니터링
- EC2 및 IAM에 관련된 위협 발견