Final Project 1주차 회고

CHLEE·2023년 6월 18일

Day 1

자산관리 시스템 구축.

요구사항

  1. 자산 구분 시스템 : 자산 분류 기준에 따라 수립된 정의 및 리소스에 적절한 태그 설정

  2. 정보 자산 점검

  • CCE(Common Configuration Enuymeration), CVE(Common Vulnerabilities and Exposure) 취약점
  1. 모니터링 및 알람
    취약성 점검 결과 알림
    일별 점검 결과 리포트

  1. 시스템 전반에 가용성, 내결함성, 확장성, 보안성이 고려된 서비스들이 포함.

  2. 하나 이상의 컴퓨팅 유닛에 대한 CI/CD 파이프라인이 구성.

  3. 시스템 메트릭 또는 저장된 데이터에 대한 하나 이상의 시각화된 모니터링 시스템이 구축.

"자산관리"와 "취약점 점검"이라는 것이 다소 생소해서 여러가지 공부가 필요할 것으로 예상된다.

먼저 CCE와 CVE가 무엇인지 알아보자

CCE (Common Configuration Enumeration)

  • 사용자에게 허용된 권한 이상의 동작을 허용하거나, 범위 이상의 정보 열람·변조·유출 등을 가능하게 하는 시스템 설정 상의 취약점

→ 진단 방법 : 정보시스템 (서버, 네트워크, DBMS, WEB/WAS, PC등)의 설정값을 통하여 진단

→ 조치 여부 : 관리자가 직접 환경 설정값 변경을 통해 자체 개선이 가능

[Note][https://nvd.nist.gov/config/cce/](https://nvd.nist.gov/config/cce/index)

CVE (Common Vulnerabilities and Exposures)

  • 컴퓨터 하드웨어 또는 소프트웨어 결함이나 체계, 설계상의 취약점
  • CVE는 공개적으로 알려진 보안 취약점에 대한 공통 식별자 목록으로, 표준화된 CVE 항목은 서비스 적용 범위를 평가할 수 있는 기준을 제공
  • CVE는 다음과 같은 규칙으로 만들어진다. → CVE-(연도)-(순서)

→ 진단 방법 : 어플리케이션의 취약점 진단

→ 조치 여부 : 설계상의 취약점이기 때문에 자체 개선이 불가능하여 제조사의 공식 패치에 의존

[Note] https://cve.mitre.org/

출처 : https://shuu.tistory.com/50

취약점에 대한 정보를 AWS 서비스에 넣어서 점검하는건지..? 실제로 KISA(한국인터넷진흥원)에서 취약점 분석,평가,점검 가이드를 찾을 수 있었다.

Day 2

정보자산에 대한 취약점 점검과 관련된 AWS 서비스에 대해 조사.

AWS Inspector

https://aws.amazon.com/ko/inspector/

규모에 맞는 지속적인 자동 취약성 관리

Amazon Inspector는 소프트웨어 취약성 및 의도하지 않은 네트워크 노출에 대해 AWS 워크로드를 지속적으로 스캔하는 취약성 관리 서비스입니다. AWS Management Console에서 클릭 몇 번으로 조직의 모든 계정에서 Amazon Inspector를 사용할 수 있습니다. 일단 시작되면 실행 중인 Amazon Elastic Compute Cloud(EC2) 인스턴스, Amazon Elastic Container Registry(ECR)에 상주하는 컨테이너 이미지 및 AWS Lambda 함수를 규모에 따라 자동으로 검색하고 즉시 알려진 취약성에 대한 평가를 시작합니다.

Amazon Inspector는 CVE(Common Vulnerabilities and Exposures) 정보를 네트워크 액세스 및 악용 가능성과 같은 요인과 연관시켜 각 결과에 대해 매우 상황에 맞는 위험 점수를 계산합니다. 이 점수는 치료 대응 효율성을 개선하기 위해 가장 심각한 취약점의 우선 순위를 지정하는 데 사용됩니다. 모든 결과는 새로 설계된 Amazon Inspector 콘솔에 집계되고 AWS Security Hub 및 Amazon EventBridge로 푸시되어 워크플로를 자동화합니다. 리소스 소유자가 보고 수정할 수 있도록 컨테이너 이미지에서 발견된 취약성도 Amazon ECR로 전송됩니다. Amazon Inspector를 사용하면 소규모 보안 팀과 개발자도 AWS 워크로드 전반에서 인프라 워크로드 보안 및 규정 준수를 보장할 수 있습니다.

AWS Systems Manager

https://aws.amazon.com/ko/systems-manager/

AWS 리소스에 대한 운영 통찰력을 확보하고 조치를 수행

AWS Systems Manager는 AWS 인프라에 대한 가시성과 제어를 제공합니다. Systems Manager는 통합된 사용자 인터페이스를 제공하므로 여러 AWS 서비스의 운영 데이터를 보고 AWS 리소스 전체에서 운영 작업을 자동화할 수 있습니다. Systems Manager를 사용하면 Amazon EC2 인스턴스, Amazon S3 버킷 또는 Amazon RDS 인스턴스와 같은 리소스를 애플리케이션별로 그룹화하고, 모니터링과 문제 해결을 위해 운영 데이터를 보고, 리소스 그룹에 조치를 취할 수 있습니다. Systems Manager는 리소스 및 애플리케이션 관리를 간소화하고, 운영 문제를 탐지 및 해결하는 시간을 단축하며, 인프라를 대규모로 안전하게 운영 및 관리할 수 있게 해줍니다.

AWS Config

https://aws.amazon.com/ko/config/

리소스 인벤토리 및 변경 추적

AWS Config는 AWS 리소스 구성을 측정, 감사 및 평가할 수 있는 서비스입니다. Config는 AWS 리소스 구성을 지속적으로 모니터링 및 기록하고, 원하는 구성을 기준으로 기록된 구성을 자동으로 평가해 줍니다. Config를 사용하면 AWS 리소스 간 구성 및 관계 변화를 검토하고, 자세한 리소스 구성 기록을 분석하고, 내부 지침에 지정되어 있는 구성을 기준으로 전반적인 규정 준수 여부를 확인할 수 있습니다. 이에 따라 규정 준수 감사, 보안 분석, 변경 관리 및 운영 문제 해결 작업을 간소화할 수 있습니다.

AWS Security Hub

AWS 계정 전반에 걸쳐 발생하는 보안 알림을 통합관리하고 규정 준수 검사 자동화를 제공하는 서비스.

통합 보안 관리 및 규정 준수를 위한 AWS Security Hub 활용하기 – 김세준:: AWS Builders Online Series

더불어 SIEM이라는 키워드도 알게 되었다.

SIEM이란 무엇인가요?

SIEM이란, Security Information and Event Management의 약자입니다.
계정 보안, 네트워크 보안, 애플리케이션 보안 등 보안 시스템 전체에서 발생하는 로그와 이벤트를 수집하여 보안 현황을 모니터링하고 탐지된 이상징후를 알려주는 솔루션을 의미합니다.

Day 3

KR) [디지털 다카포 2022] 자동화된 취약성 관리를 위한 Amazon Inspector

Inspector -> Security Hub -> EventBridge 순으로 아키텍처를 구성해서 Automate Actions를 통해 모니터링 및 알림을 자동화 할 수 있다!

그 동안 실습에서 서비스나 리소스에 태그를 붙이는 것은 스킵하면서 지나갔는데 실제 서비스를 운영하는 단계에서 태그를 잘 다는 것이 중요한 이유에 대해서 알아보았다.

비용 최적화로 나아가는 첫 단추, AWS Tagging을 활용하여 비용 가시성 확보하기 - 유정연, AWS | AWS Builders 온라인 시리즈

자산을 구분하기 위해서는 취약성 점검 전에 리소스 그룹과 태그가 잘 되어있는지 확인이 필요하다. 관리 측면에서 뿐만아니라 자동화, 규제 준수, 그리고 비용문제에 있어서도 중요하다는 것을 배웠다.

추가 미팅 후 결정된 사항

  • 리소스와 태그 관리 강화 - AWS Resource Groups & Tag Editor를 활용할 계획. AWS Resource Groups
  • 모니터링 및 알림 부분 강화 - 일일 리포트 알림과 취약점 점검 결과 알림을 일괄로 이메일 알림을 하는 것 보다 일일 리포트 알림은 이메일, 취약점 점검 결과 알림은 애플리케이션을 통해 하는 것으로 결정(Slack 활용할 예정)
  • 메트릭 수집과 시각화된 모니터링은 AWS Managed Service - Prometheus, Grafana를 활용할 예정

Day 4

아키텍처 수정사항

EventBridge를 두 개를 따로 생성하였고 각각 SES와 Slack으로 나누어서 가용성을 높을 것이라고 생각하여 설계했다.


Systems Manager에 붙은 Cloud Watch의 로그를 잘 처리하기 위해서 SQS에 DLQ를 붙여서 내결함성과 가용성을 높였다.
https://aws.amazon.com/ko/what-is/dead-letter-queue/

Day 5

아키텍처

만들어진 아키텍처를 바탕으로 AWS Pricing Calculator를 통하여 예상되는 비용을 산정했다.

사용할 서비스들을 실제로 사용할 만큼의 정보를 입력하면 알아서 비용을 계산해 준다. 장바구니에 담듯이 서비스마다 추가할 수 있어서 편리했다. 생각보다 사용할 양에 대한 자세한 내용을 요구하고 있어 정확한 정보를 가져야 하는 것을 배웠다.

다행히 예산이 여유가 있어서 데이터베이스로 RDS를, 로그 저장용으로 S3를 추가하여 좀 더 안정적인 서비스를 구성할 수 있었다.

CI/CD를 위해 Github actions를 사용하기로 하였고 콘솔로 구현이 완성되면 Terraform으로 코드화도 할 예정이다. 기본적인 리소스들을 구성 하면서 Github actions와 Terraform이 잘 연결되는지 테스트를 하였다.

  • Github actions → Terraform 에서 tfstate 파일이 달라짐에 따라 terraform destroy가 되지 않는 문제 발생
  • 해결 방법
    1. 백엔드 버킷과 DynamoDB 테이블 미리 생성 (워크스페이스 따로 만들어서 올렸음)
    2. 본체 테라폼에 생성해놓은 S3 버킷으로 state 파일 저장하도록 셋팅
    3. Github actions에서 apply 및 destroy 할 때 S3 버킷에 저장해놓은 state 파일을 읽어옴

업무 분담까지 완료하였고 다음주 있을 본격적인 구현단계에 앞서 좀 더 연구하고 조사해봐야겠다.😎

profile
CHLEE
🤗
이전 포스트

성능 테스트

다음 포스트

Final Project 2주차 회고

0개의 댓글