통합 이해

통합 이해

온보딩 절차를 완료한 뒤에는 IAM 임시 위임으로 통합을 구축할 수 있어요. 완전한 통합은 일반적으로 세 가지 주요 작업 범주를 포함해요.

출처: 문서

본문

1. 사용자 경험 및 워크플로 설계

파트너 애플리케이션에 고객을 임시 위임 워크플로로 안내하는 프런트엔드 경험을 구축하세요. 파트너 애플리케이션은 다음을 해야 해요.

  • 고객이 임시 액세스를 부여할 수 있는 명확한 온보딩 또는 구성 흐름을 제시합니다. "Deploy with IAM temporary delegation" 같은 명확한 라벨로 이 작업을 표시합니다.
  • CreateDelegationRequest API가 반환하는 콘솔 링크를 사용해 고객을 AWS Management Console로 리디렉션해 위임 요청을 검토·승인하게 합니다.
  • 어떤 권한이 요청되는지, 왜 요청되는지에 대한 적절한 메시지를 제공합니다. 고객은 위임 요청 세부 정보 페이지에서 이 메시지를 볼 수 있습니다.
  • 고객이 AWS에서 승인을 완료한 뒤 여러분의 애플리케이션으로 돌아오는 것을 처리합니다.

임시 위임 요청의 모범 사례

파트너 애플리케이션에 임시 위임을 구현할 때는 다음 모범 사례를 따라 고객이 요청의 진위와 정확성을 확인할 수 있게 도와주세요.

  1. 요청 메시지에 사용자 식별 컨텍스트 포함 — 위임 요청 메시지에 사용자별 컨텍스트를 포함해야 합니다. 이 정보는 사용자가 기존 파트너 워크플로에서 요청을 식별하고 정당한 요청을 구별하는 데 도움이 됩니다. 요청 메시지에 제안되는 정보:

    • 서비스에서의 고객 계정 식별자 또는 사용자 이름
    • 작업 공간 이름, 구독 ID 또는 조직 식별자
    • 액세스되는 특정 리소스(클러스터 이름, 프로젝트 이름, 환경)
    • 이 위임 시도에 대해 생성된 고유 트랜잭션 또는 요청 식별자

    요청 메시지 예시:

    Request from Partner A workspace "production-analytics"
Account: [email protected]
Workspace ID: 1234ABCD
Cluster: ml-training-cluster-01
Request ID: 1111-2222-3333-4444

  2. 선택 사항: 위임 시작 시 AWS 계정 ID 포함 — 고객 계정 ID를 사용할 수 있다면 위임 요청에 포함합니다. 이 검증 단계는 고객의 의도와 위임 토큰 사이에 추가 바인딩을 만듭니다.

  3. 보안 검증을 위한 요청 메시지 설계 — 요청 메시지를 구조화해 고객이 액세스를 부여하기 전에 정당성을 자신 있게 검증할 수 있게 합니다. 사용자 경험 요구 사항:

    • AWS로 리디렉션하기 전에 애플리케이션 인터페이스에서 요청 메시지를 눈에 띄게 표시
    • 고객의 현재 작업과 직접 연결되는 명확하고 설명적인 언어 사용
    • 어떤 위임 요청에도 적용될 수 있는 일반적 메시지 피하기
    • 고객이 요청이 의도한 워크플로와 일치하는지 검증할 충분한 세부 정보 포함
    • 위임 액세스를 받을 AWS 계정 ID 표시
    • 애플리케이션이 요청할 권한을 명확히 설명
    • AWS 동의 화면으로 리디렉션하기 전에 애플리케이션에 확인 안내를 포함:
    ⚠️ Redirecting to IAM Temporary Delegation
You are about to grant [Your Service Name] temporary access to your AWS account.

Before clicking "Allow" on the AWS consent screen:
• Verify the request details match your current action
• Confirm the AWS account ID matches your intended account
• Make sure you initiated this request from [Your Service Name]

  4. 세션 바인딩 권장 사항 — AWS IAM이 핵심 권한 부여 흐름을 처리하는 동안, 세션 무결성을 강화하기 위해 애플리케이션에서 다음 사례를 구현합니다.

    • 각 위임 시도에 대해 고유하고 일회용인 요청 식별자 생성
    • 위임 요청을 고객의 활성 애플리케이션 세션과 연결
    • 위임 프로세스에 따라 적절한 요청 만료 구현
    • 위임 콜백이 요청 시작 컨텍스트와 일치하는지 검증
    • 보안 모니터링을 위해 모든 위임 요청 시작·완료 기록

이 모범 사례를 따르면 더 안전한 임시 위임 경험을 만드는 데 도움이 됩니다.

2. API 통합

IAM 임시 위임 API를 사용해 위임 요청을 보내고 관리하세요. AWS 계정이 등록된 후 다음 API에 액세스할 수 있어요.

  • IAM CreateDelegationRequest — 고객의 AWS 계정에 대한 위임 요청을 만듭니다. 이 API는 요청 검토·승인을 위해 고객을 리디렉션할 콘솔 링크를 반환합니다.
  • AWS STS GetDelegatedAccessToken — 고객이 위임 요청을 승인한 후 임시 AWS 자격 증명을 검색합니다. 이 자격 증명을 사용해 고객의 계정에서 작업을 수행합니다.

통합은 요청 생성, 상태 모니터링, 승인 시 임시 자격 증명 검색을 포함해 위임 요청의 전체 수명 주기를 처리해야 해요.

3. 리소스 구성 및 오케스트레이션

임시 자격 증명을 얻은 후 고객의 AWS 계정에서 리소스를 구성하는 데 필요한 워크플로를 오케스트레이션하세요. 다음이 포함될 수 있어요.

  • AWS 서비스 API를 직접 호출해 리소스 생성·구성
  • AWS CloudFormation 템플릿으로 인프라 배포
  • 지속적 액세스를 위한 IAM 역할 생성(권한 경계 사용 필요). 심층 방어(defense-in-depth) 조치로 무작위 생성 접미사가 있는 이름 같은 동적 역할 이름을 사용하길 권장합니다. 이렇게 하면 각 고객 계정의 역할 이름이 고유하고 예측 불가능해집니다.

오케스트레이션 로직은 멱등(idempotent)이어야 하고 실패를 우아하게 처리해야 해요. 고객이 위임 승인을 재시도하거나 수정할 수 있기 때문이에요.

더 알아보기 (Learn more)