Machine-to-machine 자격 증명 관리

M2M(MachineMachine-to-machine) 인증을 사용하면 AWS에서 실행되는 서비스와 애플리케이션이 서로 안전하게 통신하여 리소스와 데이터에 액세스할 수 있습니다. 시스템 인증 시스템은 장기 정적 자격 증명을 사용하는 대신 임시 자격 증명 또는 토큰을 발급하여 신뢰할 수 있는 시스템을 식별합니다. 이를 통해 사람의 개입 없이 환경의 특정 부분에 액세스할 수 있는 시스템을 정확하게 제어할 수 있습니다. 잘 설계된 시스템 인증은 광범위한 자격 증명 노출을 제한하고, 권한의 동적 취소를 활성화하고, 자격 증명 교체를 간소화하여 보안 태세를 개선하는 데 도움이 됩니다. 일반적인 시스템 인증 방법에는 EC2 인스턴스 프로파일, Amazon Cognito 클라이언트 자격 증명 권한 부여, 상호 인증된 TLS(mTLS) 연결 및 IAM Roles Anywhere가 포함됩니다. 이 섹션에서는 AWS에서 안전하고 확장 가능한 M2M 인증 흐름을 구현하는 방법에 대한 지침을 제공합니다.

EC2 인스턴스 프로파일

AWS APIs를 호출해야 하는 Amazon Elastic Compute Cloud(Amazon EC2)에서 실행되는 애플리케이션 또는 서비스가 있는 경우 EC2 인스턴스 프로파일을 사용하는 것이 좋습니다. 인스턴스 프로파일을 사용하면 EC2 인스턴스에서 실행되는 애플리케이션이 수명이 긴 정적 IAM 액세스 키 없이도 다른 AWS 서비스에 안전하게 액세스할 수 있습니다. 대신 인스턴스에 IAM 역할을 할당하여 인스턴스 프로파일을 통해 필요한 권한을 제공해야 합니다. 그러면 EC2 인스턴스가 인스턴스 프로파일에서 임시 보안 자격 증명을 자동으로 획득하여 다른 AWS 서비스에 액세스할 수 있습니다. 

다음은 이 시나리오를 설명하는 다이어그램입니다

1. AWS API를 호출해야 하는 EC2 인스턴스의 애플리케이션은 인스턴스 메타데이터 항목에서 역할이 제공하는 보안 자격 증명을 검색합니다iam/security-credentials/<role-name>. 

2. 애플리케이션은 AWS API 요청에 서명하는 데 사용할 수 있는 AccessKeyIdSecretAccessKey, 및 보안 암호 토큰을 수신합니다.

3. 애플리케이션은 AWS API를 호출합니다. 역할이 API 작업을 허용하면 요청이 성공한 것입니다.

AWS 리소스에서 임시 자격 증명을 사용하는 방법에 대한 자세한 내용은 IAM 설명서의 AWS 리소스에서 임시 자격 증명 사용을 참조하세요.

장점

• 보안을 개선했습니다. 이 방법을 사용하면 EC2 인스턴스에 장기 자격 증명이 배포되지 않습니다. 자격 증명은 인스턴스 프로파일을 통해 일시적으로 제공됩니다. 

• 간편한 통합. 인스턴스에서 실행되는 애플리케이션은 추가 코딩이나 구성 없이 자격 증명을 자동으로 얻을 수 있습니다. AWS SDKs는 인스턴스 프로파일 자격 증명을 자동으로 사용합니다.

• 동적 권한. 인스턴스 프로파일에 할당된 IAM 역할을 업데이트하여 인스턴스에 사용할 수 있는 권한을 변경할 수 있습니다. 업데이트된 권한을 반영하는 새 자격 증명이 자동으로 획득됩니다. 

• 교체. AWS는 임시 자격 증명을 자동으로 교체하여 손상된 자격 증명으로 인한 위험을 줄입니다. 

• 취소. 인스턴스 프로파일에서 역할 할당을 제거하여 자격 증명을 즉시 취소할 수 있습니다.

설계 고려 사항

• EC2 인스턴스에는 연결된 인스턴스 프로파일이 하나만 있을 수 있습니다.

• 최소 권한 IAM 역할을 사용합니다. 애플리케이션에 필요한 권한만 인스턴스 프로파일의 IAM 역할에 할당합니다. 필요한 경우 최소 권한으로 시작하고 나중에 더 많은 권한을 추가합니다. 

• 역할 정책의 IAM 조건을 사용하여 태그, IP 주소 범위, 시간대 등에 따라 권한을 제한합니다. 이렇게 하면 애플리케이션이 액세스할 수 있는 서비스와 리소스가 제한됩니다.

• 필요한 인스턴스 프로파일 수를 고려합니다. EC2 인스턴스에서 실행되는 모든 애플리케이션은 동일한 프로필을 공유하며 동일한 AWS 권한을 갖습니다. 동일한 인스턴스 프로파일을 여러 EC2 인스턴스에 적용할 수 있으므로 필요한 경우 인스턴스 프로파일을 재사용하여 관리 오버헤드를 줄일 수 있습니다.

• 활동을 모니터링합니다. AWS CloudTrail과 같은 도구를 사용하여 인스턴스 프로파일 자격 증명을 사용하는 API 호출을 모니터링합니다. 자격 증명이 손상되었음을 나타낼 수 있는 비정상적인 활동이 있는지 확인합니다. 

• 불필요한 자격 증명을 삭제합니다. 자격 증명 사용을 방지하기 위해 미사용 인스턴스 프로파일에서 역할 할당을 제거합니다. IAM 액세스 어드바이저를 사용하여 미사용 역할을 식별할 수 있습니다. 

• PassRolepermission을 사용하여 사용자가 인스턴스를 시작할 때 EC2 인스턴스에 전달할 수 있는 역할을 제한합니다. 이렇게 하면 사용자가 부여된 것보다 더 많은 권한을 가진 애플리케이션을 실행할 수 없습니다.

• 아키텍처가 여러 AWS 계정에 걸쳐 있는 경우 한 계정의 EC2 인스턴스가 다른 계정의 리소스에 액세스해야 하는 방법을 고려합니다. 장기 AWS 보안 자격 증명을 포함할 필요 없이 보안 액세스를 보장하려면 교차 계정 역할을 적절하게 사용합니다.

• 인스턴스 프로파일을 대규모로 관리하려면 다음 옵션 중 하나를 사용할 수 있습니다.

  • AWS Systems Manager Automation 런북을 사용하여 인스턴스 프로파일과 EC2 인스턴스의 연결을 자동화합니다. 이 작업은 시작 시 또는 인스턴스가 실행된 후에 수행할 수 있습니다.

  • AWS 콘솔을 통해 구성하는 대신 AWS CloudFormation을 사용하여 생성 시 프로그래밍 방식으로 EC2 인스턴스에 인스턴스 프로파일을 적용합니다.

• VPC 엔드포인트를 사용하여 EC2 인스턴스에서 실행되는 애플리케이션에서 Amazon S3 및 Amazon DynamoDB와 같은 지원되는 AWS 서비스에 비공개로 연결하는 것이 좋습니다. 

Amazon Cognito 클라이언트 자격 증명 권한 부여

Amazon Cognito는 관리형 고객 자격 증명 및 액세스 관리 서비스입니다. Amazon Cognito는 클라이언트 자격 증명 권한 부여 유형을 통해 사용자 대신 시스템 또는 애플리케이션을 인증하는 기능을 포함하여 OAuth 준수 인증 흐름을 제공합니다. 이 권한 부여를 통해 애플리케이션은 임시 AWS 자격 증명을 직접 검색하여 AWS 서비스에 액세스할 수 있습니다. Amazon Cognito 클라이언트 자격 증명은 사용자 상호 작용 없이 애플리케이션에 AWS 권한을 제공하는 안전한 방법입니다. 애플리케이션은 Amazon Cognito 토큰 엔드포인트에 클라이언트 ID와 클라이언트 암호를 제공합니다. 그 대가로 다양한 리소스 및 서비스에 대한 후속 요청을 인증하는 데 사용할 수 있는 액세스 토큰을 받습니다. 이 액세스의 범위는 클라이언트 ID와 연결된 권한에 따라 결정됩니다. 요청을 수신하는 애플리케이션은 서명, 만료 타임스탬프 및 대상을 확인하여 토큰을 검증해야 합니다. 이러한 확인 후 애플리케이션은 토큰의 클레임을 검증하여 요청된 작업이 허용되는지 확인합니다.

다음 다이어그램은이 방법을 보여줍니다.

1. 서버(리소스 서버)에서 리소스를 요청하려는 애플리케이션(앱 클라이언트)은 Amazon Cognito에서 토큰을 요청합니다.

2. Amazon Cognito 사용자 풀은 액세스 토큰을 반환합니다.

3. App Client는 Resource Server에 요청을 보내고 액세스 토큰을 포함합니다.

4. Resource Server는 Amazon Cognito를 사용하여 토큰을 검증합니다.

5. 검증에 성공하고 요청된 작업이 허용되는 경우 Resource Server는 요청된 리소스로 응답합니다.

장점

• 시스템 인증. 이 메서드에는 사용자 컨텍스트나 로그인이 필요하지 않습니다. 애플리케이션은 토큰으로 직접 인증합니다.

• 단기 자격 증명. 애플리케이션은 먼저 Amazon Cognito에서 액세스 토큰을 가져온 다음 시간 제한 액세스 토큰을 사용하여 리소스 서버에서 데이터에 액세스할 수 있습니다.

• OAuth2 지원. 이 방법은 설정된 OAuth2 표준을 따르기 때문에 불일치를 줄이고 애플리케이션 개발에 도움이 됩니다.

• 보안 강화. 클라이언트 자격 증명 권한 부여를 사용하면 API 키 권한 부여 메커니즘과 달리 클라이언트 ID와 클라이언트 보안 암호가 리소스 서버로 전송되지 않으므로 보안이 강화됩니다. 클라이언트 ID와 보안 암호는 Amazon Cognito를 호출하여 시간 제한 액세스 토큰을 가져올 때만 공유되고 사용됩니다.

• 범위를 통한 세분화된 액세스 제어. 애플리케이션은 범위와 추가 클레임을 정의하고 요청하여 특정 리소스에 대한 액세스를 제한할 수 있습니다.

• 감사 추적. CloudTrail에서 수집한 정보를 사용하여 Amazon Cognito에 수행된 요청, 요청이 수행된 IP 주소, 요청을 수행한 사람, 요청이 수행된 시간 및 추가 세부 정보를 확인할 수 있습니다. 

설계 고려 사항

• 각 클라이언트 ID에 대한 액세스 범위를 필요한 최소 수준으로 신중하게 정의하고 제한합니다. 범위가 좁으면 잠재적 취약성을 줄이고 서비스가 필요한 리소스에만 액세스할 수 있습니다. 

• AWS Secrets Manager와 같은 보안 스토리지 서비스를 사용하여 자격 증명을 저장하여 클라이언트 IDs와 보안 암호를 보호합니다. 소스 코드에서 자격 증명을 확인하지 마십시오.

• CloudTrail 및 CloudWatch와 같은 도구를 사용하여 토큰 요청 및 사용을 모니터링하고 감사합니다. 문제를 나타낼 수 있는 예기치 않은 활동 패턴이 있는지 확인합니다. 

• 정기적으로 클라이언트 보안 암호 교체를 자동화합니다. 교체할 때마다 새 애플리케이션 클라이언트를 생성하고, 이전 클라이언트를 삭제하고, 클라이언트 ID와 보안 암호를 업데이트합니다. 서비스 통신을 중단하지 않고 이러한 교체를 촉진합니다. 

• 토큰 엔드포인트 요청에 속도 제한을 적용하여 침해 및 서비스 거부(DoS) 공격을 방지합니다. 

• 보안 위반이 발생할 경우 토큰을 취소하기 위한 전략을 준비합니다. 토큰은 수명이 짧지만 손상된 토큰은 즉시 무효화해야 합니다.

• AWS CloudFormation을 사용하여 프로그래밍 방식으로 Amazon Cognito 사용자 풀과 다른 서비스에 인증해야 하는 시스템을 나타내는 애플리케이션 클라이언트를 생성합니다.

• 적절한 경우 캐시 토큰을 사용하여 성능 효율성과 비용 최적화를 제공합니다.

• 액세스 토큰의 만료가 조직의 보안 태세와 일치하는지 확인합니다.

• 사용자 지정 리소스 서버를 사용하는 경우 항상 액세스 토큰을 확인하여 서명이 유효하고 토큰이 만료되지 않았으며 올바른 범위가 있는지 확인합니다. 필요에 따라 추가 클레임을 확인합니다.

• 클라이언트 자격 증명을 대규모로 관리하려면 다음 옵션 중 하나를 사용할 수 있습니다.

  • 단일 중앙 집중식 Amazon Cognito 인스턴스에서 모든 클라이언트 자격 증명의 관리를 중앙 집중화합니다. 이렇게 하면 여러 Amazon Cognito 인스턴스의 관리 오버헤드를 줄이고 구성 및 감사를 더 간단하게 만들 수 있습니다. 그러나 규모 조정을 계획하고 Amazon Cognito 서비스 할당량을 고려해야 합니다.

  • 클라이언트 자격 증명에 대한 책임을 워크로드 계정에 페더레이션하고 여러 Amazon Cognito 인스턴스를 허용합니다. 이 옵션은 유연성을 높이지만 중앙 집중식 옵션에 비해 오버헤드와 전반적인 복잡성을 높일 수 있습니다.

mTLS 연결

상호 TLS(mTLS) 인증은 클라이언트와 서버가 TLS와 함께 인증서를 사용하여 통신하기 전에 서로 인증할 수 있는 메커니즘입니다. mTLS의 일반적인 사용 사례에는 규정이 높은 산업, 사물 인터넷(IoT) 애플리케이션, business-to-business) 애플리케이션이 포함됩니다. Amazon API Gateway는 현재 기존 권한 부여 옵션 외에도 mTLS를 지원합니다. 사용자 지정 도메인에서 mTLS를 활성화하여 리전 REST 및 HTTP APIs. 요청은 베어러, JSON 웹 토큰(JWTs)을 사용하거나 IAM 기반 권한 부여를 통해 요청에 서명하여 권한을 부여할 수 있습니다. 

다음 다이어그램은 EC2 인스턴스에서 실행 중인 애플리케이션과 Amazon API Gateway에서 설정된 API에 대한 mTLS 인증 흐름을 보여줍니다.

1. API Gateway는 공개적으로 신뢰할 수 있는 인증서를 AWS Certificate Manager(ACM)에서 직접 요청합니다.

2. ACM은 인증 기관(CA)에서 인증서를 생성합니다.

3. API를 호출하는 클라이언트는 API 요청과 함께 인증서를 제공합니다.

4. API Gateway는 생성한 Amazon S3 트러스트 스토어 버킷을 확인합니다. 이 버킷에는 API에 액세스하기 위해 신뢰할 수 있는 X.509 인증서가 포함되어 있습니다. API Gateway가 요청을 진행하려면 인증서의 발급자와 루트 CA 인증서까지의 전체 신뢰 체인이 트러스트 스토어에 있어야 합니다.

5. 클라이언트의 인증서가 신뢰할 수 있는 경우 API Gateway는 요청을 승인하고 메서드를 호출합니다.

6. 연결된 API 작업(이 경우 AWS Lambda 함수)은 요청을 처리하고 요청자에게 전송되는 응답을 반환합니다.

장점

• M2M 인증. 서비스는 공유 보안 암호 또는 토큰을 사용하는 대신 서로 직접 인증합니다. 이렇게 하면 정적 자격 증명을 저장하고 관리할 필요가 없습니다.

• 변조 방지. TLS 암호화는 서비스 간에 전송 중인 데이터를 보호합니다. 타사는 통신을 읽거나 변경할 수 없습니다. 

• 간편한 통합. mTLS 지원은 주요 프로그래밍 언어 및 프레임워크에 내장되어 있습니다. 서비스는 코드 변경을 최소화하면서 mTLS를 활성화할 수 있습니다. 

• 세분화된 권한. 서비스는 특정 인증서만 신뢰하므로 허용된 호출자를 세밀하게 제어할 수 있습니다. 

• 취소. 손상된 인증서는 더 이상 신뢰할 수 없도록 즉시 취소할 수 있으므로 추가 액세스를 방지할 수 있습니다. 

설계 고려 사항

• API Gateway를 사용하는 경우:

  • 기본적으로 클라이언트는 API Gateway가 API에 대해 생성하는 execute-api엔드포인트를 사용하여 API를 호출할 수 있습니다. 클라이언트가 mTLS와 함께 사용자 지정 도메인 이름을 사용해야만 API에 액세스할 수 있도록 하려면이 기본 엔드포인트를 비활성화합니다. 자세한 내용은 API Gateway 설명서의 REST API의 기본 엔드포인트 비활성화를 참조하세요.

  • API Gateway는 인증서가 취소되었는지 여부를 확인하지 않습니다.

  • REST API에 대해 mTLS를 구성하려면 최소 TLS 버전이 1.2인 API의 리전 사용자 지정 도메인 이름을 사용해야 합니다. 프라이빗 APIs에는 mTLS가 지원되지 않습니다.

• 자체 CA에서 API Gateway에 대한 인증서를 발급하거나 AWS Private Certificate Authority에서 인증서를 가져올 수 있습니다.

• 서비스 인증서를 안전하게 발급, 배포, 갱신 및 취소하는 프로세스를 생성합니다. 가능하면 발급 및 갱신을 자동화합니다. M2M 통신의 한 쪽이 API 게이트웨이인 경우 AWS Private CA와 통합할 수 있습니다.

• 프라이빗 CA에 대한 액세스를 보호합니다. CA를 손상하면 CA가 발급한 모든 인증서에 대한 신뢰가 손상됩니다.

• 프라이빗 키를 인증서와 별도로 안전하게 저장합니다. 키를 주기적으로 교체하여 손상된 경우 영향을 제한합니다.

• 인증서가 더 이상 필요하지 않거나 손상된 경우 즉시 취소합니다. 인증서 해지 목록을 서비스에 배포합니다. 

• 가능하면 특정 용도 또는 리소스만을 위한 인증서를 발급하여 손상된 경우 유틸리티를 제한합니다.

• CA 또는 인증서 해지 목록(CRL) 인프라의 인증서 만료 및 중단에 대한 비상 계획이 있어야 합니다. 

• 시스템에서 인증서 실패 및 중단을 모니터링합니다. 문제를 나타낼 수 있는 실패의 급증에 주의하세요.

• AWS Private CA와 함께 AWS Certificate Manager(ACM)를 사용하는 경우 AWS CloudFormation을 사용하여 퍼블릭 및 프라이빗 인증서를 프로그래밍 방식으로 요청할 수 있습니다.

• ACM을 사용하는 경우 AWS Resource Access Manager(AWS RAM)를 사용하여 보안 계정의 인증서를 워크로드 계정과 공유합니다.

IAM Roles Anywhere

시스템 또는 시스템이 AWS 서비스에 연결해야 하지만 IAM 역할을 지원하지 않는 경우 M2M 자격 증명 관리에 IAM Roles Anywhere를 사용하는 것이 좋습니다. IAM Roles Anywhere는 퍼블릭 키 인프라(PKI)를 사용하여 임시 보안 자격 증명을 사용하여 워크로드에 대한 액세스 권한을 부여하는 IAM의 확장입니다. CA를 통해 또는 AWS Private CA에서 발급할 수 있는 X.509 인증서를 사용하여 CA와 IAM Roles Anywhere 간에 트러스트 앵커를 설정할 수 있습니다. IAM 역할과 마찬가지로 워크로드는 역할에 연결된 권한 정책에 따라 AWS 서비스에 액세스할 수 있습니다. 

다음 다이어그램은 IAM Roles Anywhere를 사용하여 AWS를 외부 리소스와 연결하는 방법을 보여줍니다.

1. 트러스트 앵커를 생성하여 AWS 계정과 온프레미스 워크로드에 인증서를 발급하는 CA 간에 신뢰를 설정합니다. 인증서는 IAM Roles Anywhere에 트러스트 앵커(신뢰 루트)로 등록한 CA에서 발급됩니다. CA는 기존 퍼블릭 키 인프라(PKI) 시스템의 일부이거나 AWS Private Certificate Authority로 생성하고 ACM으로 관리하는 CA일 수 있습니다. 이 예제에서는 ACM을 사용합니다.

2. 애플리케이션은 IAM Roles Anywhere에 인증을 요청하고 퍼블릭 키(인증서에 인코딩됨)와 해당 프라이빗 키로 서명된 서명을 전송합니다. 애플리케이션은 요청에서 수임할 역할도 지정합니다.

3. IAM Roles Anywhere는 요청을 수신하면 먼저 퍼블릭 키를 사용하여 서명을 검증한 다음 트러스트 앵커에서 인증서가 발급되었는지 확인합니다. 두 검증이 모두 성공하면 애플리케이션이 인증되고 IAM Roles Anywhere는 AWS Security Token Service(AWS STS)를 호출하여 요청에 지정된 역할에 대한 새 역할 세션을 생성합니다.

4. IAM Roles Anywhere가 제공하는 자격 증명 헬퍼 도구를 사용하여 인증서로 서명을 생성하는 프로세스를 관리하고 엔드포인트를 호출하여 세션 자격 증명을 얻습니다. 도구는 자격 증명을 표준 JSON 형식으로 호출 프로세스에 반환합니다.

5. 온프레미스 워크로드는 IAM과 PKI 간에이 브리지된 신뢰 모델을 사용하여 이러한 임시 자격 증명(액세스 키, 보안 키 및 세션 토큰)을 사용하여 장기 자격 증명 없이 AWS 리소스와 상호 작용할 수 있는 IAM 역할을 수임합니다. AWS CLI 또는 AWS SDKs.

장점

• 영구 자격 증명이 없습니다. 애플리케이션에는 광범위한 권한이 있는 장기 AWS 액세스 키가 필요하지 않습니다. 

• 세분화된 액세스. 정책은 특정 엔터티에 대해 수임할 수 있는 IAM 역할을 결정합니다. 

• 컨텍스트 인식 역할. 인증된 엔터티의 세부 정보를 기반으로 역할을 사용자 지정할 수 있습니다.

• 취소. 신뢰 권한을 즉시 취소하면 엔터티가 역할을 수임하는 것이 차단됩니다.

설계 고려 사항

• 서버는 인증서 기반 인증을 지원할 수 있어야 합니다. 

• 트러스트 앵커가 구성된 계정에 aws:SourceAccount 대해 aws:SourceArn 또는를 사용하도록 신뢰 정책을 잠그는 것이 좋습니다. 

• 보안 주체 태그는 인증서 세부 정보에서 전달됩니다. 여기에는 일반 이름(CN), 주체 대체 이름(SAN), 주체 및 발급자가 포함됩니다.

• ACM을 사용하는 경우 AWS RAM을 사용하여 보안 계정의 인증서를 워크로드 계정과 공유합니다.

• 운영 체제(OS) 파일 시스템 권한을 사용하여 소유 사용자에 대한 읽기 액세스를 제한합니다.

• 키를 소스 제어로 확인하지 마십시오. 소스 코드와 별도로 저장하여 변경 세트에 실수로 포함할 위험을 줄입니다. 가능하면 안전한 스토리지 메커니즘을 사용하는 것이 좋습니다.

• 인증서를 교체하고 취소하는 프로세스가 있는지 확인합니다.