AWS Secrets Manager이 나오게 된 배경

• 과거에는 DB에서 정보를 검색하는 사용자 지정 애플리케이션을 생성하면 일반적으로 DB에 엑세스하기 위한 자격 증명(보안 암호)을 애플리케이션에 직접 포함시켰다.

• 이는 자격 증명을 교체할 시기가 되면 새 자격 증명을 생성하는 것보다 더 많은 작업을 해야 했다.

• 자격 증명을 공유하는 애플리케이션이 여러 개 있는데 이러한 애플리케이션 중 하나를 업데이트하지 못한 경우 해당 애플리케이션에 오류가 발생한다.

• 이러한 위험 때문에 많은 고객들은 정기적으로 자격 증명을 교체하지 않기로 결정하며, 이 위험 대신 다른 위험에 직면하게 되었다.

• Secrets Manager는 코드의 암호를 포함해 하드 코딩된 자격 증명을 Secrets Manager에서 프로그래밍 방식으로 보안 암호를 검색하도록 하는 API 호출로 바꿀 수 있다.

• 이렇게 하면 보안 암호가 코드에 더 이상 존재하지 않기 때문에 코드를 검사하는 누군가에 의해 보안 암호가 노출혹은 손상 되지 않도록 방지할 수 있다.

• 또한 사용자가 지정한 일정에 따라 Secrets Manager가 자동으로 보안 암호를 교체하도록 구성할 수 있다.

기존 AWS Secrets Manager 시나리오

• 아래 그림은 시나리오를 설명한 다이어그램이다. 이 다이어그램은 Secrets Manager에 데이터베이스의 자격 증명을 저장한 후 이 데이터베이스에 액세스하기 위해 애플리케이션에서 자격 증명을 사용하는 방법을 보여준다.

1. 데이터베이스 관리자가 MyCustomApp이라는 애플리케이션에서 사용할 수 있도록 인력 데이터베이스에 대한 자격 증명 세트를 생성한다. 또한 관리자는 이 애플리케이션에서 인력 데이터베이스에 액세스하는 데 필요한 권한을 사용하여 이러한 자격 증명을 구성한다.
2. DBA가 Secrets Manager에서 자격 증명을 MyCustomAppCreds라는 보안 암호로 저장한다. 그런 다음 Secrets Manager는 자격 증명을 암호화하여 보안 암호 내에 보호 되는 보안 암호 텍스트로 저장합니다.
3. MyCustomApp에서 데이터베이스에 액세스하는 경우 이 애플리케이션은 Secrets Manager에 MyCustomAppCreds라는 보안 암호를 쿼리합니다.
4. Secrets Manager는 이 보안 암호를 검색하고 보호되는 동안 보안 암포 텍스트의 암호를 해독해 보안 채널을 통해 클라이언트 앱에 보안 암호를 반환합니다.
5. 이 클라이언트 애플리케이션은 응답에서 자격 증명, 연결 문자열 및 및 기타 필요한 정보를 구문 분석한 다음 이러한 정보를 사용해 데이터베이스 서버에 엑세스한다.