# 아키텍처 다이어그램 문서화 및 중앙 집중화
<a name="document-and-centralize-architecture-diagrams"></a>

 보안 이벤트에 빠르고 정확하게 대응하려면 시스템과 네트워크가 어떻게 설계되는지 이해해야 합니다. 이러한 내부 패턴을 이해하는 것은 인시던트 대응뿐만 아니라 모범 사례에 따라 패턴이 설계된 애플리케이션 전반의 일관성을 확인하는 데에도 중요합니다. 또한 이 설명서가 최신 상태이고 새 아키텍처 패턴에 따라 정기적으로 업데이트되는지 확인해야 합니다. 다음과 같은 항목을 자세히 설명하는 설명서와 내부 리포지토리를 개발해야 합니다.
+ **AWS 계정 구조** - 다음을 알아야 합니다.
  +  AWS 계정이 몇 개 있나요?
  +  이러한 AWS 계정은 어떻게 구성되나요?
  +  AWS 계정의 비즈니스 소유자는 누구인가요?
  +  서비스 제어 정책(SCP)을 사용하시나요? 그렇다면 SCP를 사용하여 구현되는 조직 가드레일은 무엇인가요?
  +  사용할 수 있는 리전과 서비스를 제한하나요?
  +  사업부와 환경(개발/테스트/프로덕션) 간에는 어떤 차이가 있나요?
+ **AWS 서비스 패턴** 
  +  어떤 AWS 서비스를 사용하나요?
  +  가장 널리 사용되는 AWS 서비스는 무엇인가요?
+ **아키텍처 패턴** 
  +  어떤 클라우드 아키텍처를 사용하나요?
+ **AWS 인증 패턴** 
  +  개발자는 일반적으로 AWS에 어떻게 인증하나요?
  +  IAM 역할, 사용자 또는 둘 다 사용하나요? AWS에 대한 인증이 ID 제공업체(idP)에 연결되어 있나요?
  +  IAM 역할 또는 사용자를 직원 또는 시스템에 어떻게 매핑하나요?
  +  더 이상 권한이 없는 경우 어떻게 액세스 권한이 취소되나요?
+ **AWS 권한 부여 패턴** 
  +  개발자는 어떤 IAM 정책을 사용하나요?
  +  리소스 기반 정책을 사용하시나요?
+ **로깅 및 모니터링** 
  +  어떤 로깅 소스를 사용하며 어디에 저장되나요?
  +  AWS CloudTrail 로그를 집계하나요? 그렇다면 어디에 저장되나요?
  +  CloudTrail 로그를 쿼리하려면 어떻게 해야 하나요?
  +  Amazon GuardDuty를 활성화했나요?
  +  GuardDuty 조사 결과(예: 콘솔, 티켓팅 시스템, SIEM)에 액세스하려면 어떻게 해야 하나요?
  +  조사 결과 또는 이벤트가 SIEM에서 집계되나요?
  +  티켓이 자동으로 생성되나요?
  +  조사를 위해 로그를 분석하기 위한 도구에는 어떤 것이 있나요?
+ **네트워크 토폴로지** 
  +  네트워크의 디바이스, 엔드포인트 및 연결은 물리적 또는 논리적으로 어떻게 배열되나요?
  +  네트워크는 AWS와 어떻게 연결되나요?
  +  환경 간에 네트워크 트래픽은 어떻게 필터링되나요?
+ **외부 인프라** 
  +  외부용 애플리케이션은 어떻게 배포되나요?
  +  공개적으로 액세스할 수 있는 AWS 리소스에는 어떤 것이 있나요?
  +  외부로 향하는 인프라가 포함된 AWS 계정에는 어떤 것이 있나요?
  +  어떤 DDoS 또는 외부 필터링이 있나요?

 내부 기술 다이어그램과 프로세스를 문서화하면 인시던트 대응 분석가의 작업이 쉬워지므로 보안 이벤트에 대응할 수 있는 제도적 지식을 빠르게 얻을 수 있습니다. 내부 기술 프로세스를 철저히 문서화하면 보안 조사가 간소화될 뿐만 아니라 프로세스의 합리화 및 평가에도 도움이 됩니다.