기존 사용자 2명 간에 전환하여 AWS Secrets Manager 보안 암호 교체 - AWS Secrets Manager

문서의 영문과 번역 사이에 충돌이 있는 경우에는 영문 버전을 따릅니다. 번역 버전은 기계 번역을 사용하여 제공합니다.

기존 사용자 2명 간에 전환하여 AWS Secrets Manager 보안 암호 교체

보안 리소스에 대한 보안 암호를 자동으로 교체하도록 AWS Secrets Manager를 구성할 수 있습니다.

이 주제에서는 두 사용자를 생성하고 사용자 간 교체를 허용하도록 시스템의 교체를 구성하는 방법을 설명합니다. 필요한 경우 암호를 변경할 수 있습니다. 이를 통해 사용자 계정을 하나로만 제한한 시나리오에서 가동 중지가 발생할 가능성을 제거할 수 있습니다. 이러한 경우 보안 암호 버전의 암호 이외의 암호로 변경합니다. 각 버전은 각 교체 주기 시 각 사용자 간에 번갈아 가며 사용자의 변경 사항을 캡처해야 합니다.

관리자가 처음 두 사용자에 대한 암호를 변경할 수 있는 승격된 권한을 가진 세 번째 "마스터" 사용자를 생성하도록 한 경우 이렇게 하는 것이 좋습니다. 이는 사용자에게 자신의 암호를 변경하는 권한을 갖도록 허용하는 것보다 더 안전합니다. 이러한 방식으로 시나리오를 구성하는 경우 첫 번째 보안 암호와 번갈아 사용자의 암호를 변경하는 데 사용할 두 번째 보안 암호를 생성해야 합니다. 먼저 "마스터" 보안 암호를 생성하여 "사용자" 보안 암호를 구성할 때 이를 참조할 수 있게 합니다.

Secrets Manager에서 제공되는 템플릿으로 구현된 시나리오는 현재 자격 증명을 비활성화하지만 즉시 삭제하지는 않습니다. 대신 Secrets Manager에서 현재 자격 증명이 있는 보안 암호 버전을 AWSPREVIOUS 스테이징 레이블로 표시합니다. 이를 통해 하나의 추가적인 교체 주기 동안 해당 자격 증명이 "마지막으로 확인된 정상" 자격 증명으로 보존됩니다. Secrets Manager는 현재 자격 증명에 문제가 발생할 경우 복구하는 데 사용할 수 있도록 자격 증명을 유지합니다.

Secrets Manager는 이 주제의 뒷부분에 설명된 바와 같이 교체 기능을 사용하여 사용자가 다시 활성 서비스로 전환될 때 두 번째 교체 주기 후에만 자격 증명을 제거합니다. 즉, 지정된 일수에 대해서만 자격 증명 집합을 유효하게 하려면 교체 기간을 1에서 절반을 뺀 값으로 설정하는 것이 좋습니다. 이를 통해 두 교체 주기가 모두 완료되며 자격 증명이 지정된 기간 내에 완전히 사용 중지될 수 있습니다.

예를 들어 규정 준수 필수 최대 자격 증명 기간(최대 90일)이 있는 경우 교체 간격을 44일(90/2 - 1 = 44)로 설정하는 것이 좋습니다. Secrets Manager는 0일에 교체 시 새 자격 증명을 생성하고 AWSCURRENT 레이블을 지정합니다. 44일에 다음 교체에서는 해당 자격 증명을 가진 보안 암호가 AWSPREVIOUS로 강등되고 클라이언트는 이를 사용하여 적극적으로 중단합니다. 88일에 다음 교체에서는 해당 버전에서 모든 스테이징 레이블이 제거됩니다. 이때 Secrets Manager에서 해당 버전이 완전히 사용 중지되며, 데이터베이스의 사용자가 새로운 암호로 재활용되어 주기가 다시 시작됩니다.

교체 시 레이블을 사용해 두 사용자 간에 교대로 적용하는 방법

스테이징 레이블을 사용하면 Secrets Manager에서 두 사용자 간에 앞/뒤로 전환할 수 있습니다. AWSCURRENT 레이블이 지정된 사용자는 클라이언트에서 적극적으로 사용합니다. Lambda 함수 교체가 트리거되면 교체 프로세스에서 비활성 상태의 두 번째 사용자에게 새 암호를 할당합니다. Secrets Manager는 그러한 자격 증명을 보안 암호의 새 버전에 저장합니다. 새 보안 암호 버전의 자격 증명을 사용한 액세스가 잘 작동하는지 확인하면 교체 프로세스에서 AWSCURRENT 레이블을 새 버전으로 이동하여 활성 버전으로 만듭니다. 다음에 트리거할 때 Secrets Manager의 역할은 두 사용자 계정을 역전시킵니다.

기본 예제 시나리오

아래에서는 이 시나리오에 대해 좀 더 자세히 설명합니다.

  1. 이 시나리오는 단일 버전 "A"를 가진 보안 암호를 사용하여 데이터베이스에 액세스하는 애플리케이션으로 시작합니다. 보안 암호의 A 버전에는 AWSCURRENT 레이블이 연결되어 있으며 두 사용자 중 첫 번째 사용자에 대한 자격 증명을 포함하고 있습니다. 이 애플리케이션은 AWSCURRENT 레이블이 지정된 버전을 요청하여 보안 암호를 검색합니다(다음 그림에서 1 및 2단계). 그런 다음 이 애플리케이션은 보안 암호의 A 버전에 있는 자격 증명을 사용하여 데이터베이스에 액세스해(3단계) 필요한 데이터를 검색합니다(4단계).

  2. 최초 교체 중 해당 프로세스에서 보안 암호의 새 버전 "B"를 생성합니다(새로운 보안 암호가 아니라 동일한 보안 암호의 새로운 버전). 그리고 사용자 이름을 두 번째 사용자로 전환하고 새 암호를 생성한다는 점을 제외하면 A 버전의 모든 세부 정보를 복제합니다. 그런 다음 교체 프로세스에서는 새 암호로 두 번째 사용자를 업데이트합니다. 처음에 보안 암호 버전 B에는 교체 프로세스에서 연결한 AWSPENDING 레이블이 있습니다. 사용자 지정 앱이 항상 AWSCURRENT 레이블을 요청하도록 프로그래밍되어 있는데 이 레이블이 변경되지 않았기 때문에 이 애플리케이션은 데이터베이스에 액세스하기 위한 자격 증명을 얻기 위해 계속해서 보안 암호의 원래 A 버전을 검색해 사용합니다.

  3. 제대로 작동하는지 B 버전 보안 암호를 테스트한 후 교체 프로세스는 AWSCURRENT 레이블을 A 버전에서 옮겨 보안 암호의 새로운 B 버전에 연결합니다. 또한 AWSPREVIOUS 스테이징 레이블을 AWSCURRENT 스테이징 레이블이 있는 이전 버전으로 자동으로 옮깁니다. 이를 통해 복구가 필요한 경우 "마지막으로 확인된 정상" 상태로 작동할 수 있습니다. 보안 암호의 AWSPREVIOUS 버전은 하나의 교체 주기 동안 계속 복구용으로 사용할 수 있습니다. Secrets Manager는 다음 주기에 이 보안 암호를 사용 중지합니다.

  4. 이제 보안 암호의 B 버전에 AWSCURRENT 레이블이 있으므로 사용자 지정 애플리케이션의 다음 요청은 보안 암호의 B 버전을 수신하는 것입니다. 사용자 지정 애플리케이션은 새로운 암호와 함께 두 번째 사용자를 사용하여 데이터베이스에 액세스합니다.

두 사용자 간의 교체 구성

지원 Amazon RDS 데이터베이스 중 하나에 대한 보안 암호를 사용하는 경우 Amazon RDS 데이터베이스 보안 암호 교체 활성화 단원의 절차를 따릅니다.

대신 다른 서비스 또는 데이터베이스에 대한 교체를 구성하려면 Lambda 교체 함수를 생성하고 다음 지침을 사용하여 사용자 지정합니다.

  1. 데이터베이스 또는 서비스에 두 사용자를 생성합니다. 사용하는 사용자 이름 및 암호를 적어 놓습니다. 각 사용자가 자신의 암호를 변경할 수 있는지 확인합니다.

  2. 첫 번째 사용자의 자격 증명을 사용하여 보안 암호를 생성합니다.

다른 데이터베이스 또는 서비스에 대한 AWS Secrets Manager 보안 암호 교체의 단계에 따라 사용자 지정할 수 있는 일반 Lambda 교체 함수 템플릿을 생성합니다. 7단계로 이동한 후 다음 정보를 사용하여 함수를 사용자 지정합니다.

교체 함수를 작성하기 위한 기준으로 다음 로직을 사용합니다.

  • createSecret 단계:

    • 작업을 사용하여 보안 암호의 버전을 검색합니다.AWSCURRENTGetSecretValue

    • SecretString 필드에서 보호되는 보안 암호 텍스트를 추출하고 사용할 수 있는 파일 구조로 배치합니다.

    • username 필드를 살펴보고 교대 사용자 이름을 확인합니다.

    • 교대 사용자 이름을 가진 사용자가 데이터베이스에 존재하는지 확인합니다. 교체 프로세스를 처음으로 수행하는 경우에만 해당 사용자가 존재하지 않을 수 있습니다. 이 경우 현재 사용자와 해당 권한을 복제합니다.

    • 보안 암호 구조의 사본에 있는 username 항목을 교대 사용자 이름으로 설정합니다.

    • 보호되는 리소스에서 지원하는 최대 길이 및 복잡성 요구 사항에 맞춰 새 암호를 생성합니다.

    • 보안 암호 구조의 사본에 있는 password 항목을 새 암호로 설정합니다.

    • PutSecretValue에 대한 호출에서 보안 암호 구조의 수정된 사본을 SecretString 파라미터로 전달하여 저장합니다. Secrets Manager에서는 보안 암호의 새 버전에 AWSPENDING이라는 레이블을 지정합니다.

  • setSecret 단계:

    • 작업을 사용하여 보안 암호의 버전을 검색합니다.AWSPENDINGGetSecretValue

    • SecretString 필드에서 사용자 이름 및 암호를 추출합니다.

    • 보안 리소스의 인증 시스템에 대한 명령을 실행하여 지정된 사용자의 암호를 해당 값으로 변경합니다.

  • testSecret 단계:

    • 작업을 사용하여 보안 암호의 버전을 검색합니다.AWSPENDINGGetSecretValue

    • 보안 암호의 자격 증명을 사용하여 보안 리소스에 액세스해 봅니다.

  • finishSecret 단계:

    • 레이블이 지정된 버전으로 레이블을 옮겨 지정합니다.AWSCURRENTAWSPENDING

    • (선택 사항) 보안 암호의 해당 버전에서 AWSPENDING 레이블을 제거합니다.

참고

이 시나리오에서는 보안 암호 교체 중 사용자에게 오류가 표시될 가능성이 적습니다. 사용자는 새 버전이 구성되는 동안 이전 버전을 계속해서 사용합니다. Secrets Manager에서 새 버전이 테스트된 경우에만 새 버전을 가리키도록 레이블을 전환합니다. 그러면 클라이언트에서 새 버전을 사용하기 시작합니다. 그러나 일부 서버는 암호 변경 시 전파 지연이 발생하는 서버 팜에 있기 때문에 암호가 모든 서버로 전파될 시간을 가질 수 있도록 (테스트하기 전에 대부분의 경우 setSecret 단계에서) 적절한 지연 시간을 포함해야 합니다. 또한 위험을 줄이기 위해 이러한 상황에서 클라이언트 애플리케이션에 적절한 재시도 기능을 포함해야 합니다.