기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

보안 모범 사례

Terraform AWS 공급자를 안전하게 사용하려면 인증, 액세스 제어 및 보안을 적절하게 관리하는 것이 중요합니다. 이 섹션에서는 다음에 대한 모범 사례를 간략하게 설명합니다.

이러한 모범 사례를 따르면 Terraform을 사용하여 AWS 인프라를 관리할 때 보안 태세를 강화하는 데 도움이 됩니다.

최소 권한 원칙을 따릅니다.

최소 권한은 사용자, 프로세스 또는 시스템이 의도한 기능을 수행하는 데 필요한 최소 권한만 부여하는 것을 참조하는 기본 보안 원칙입니다. 이는 액세스 제어의 핵심 개념이며 무단 액세스 및 잠재적 데이터 침해에 대한 예방 조치입니다.

최소 권한의 원칙은 Terraform이와 같은 클라우드 공급자에 대해 작업을 인증하고 실행하는 방법과 직접 관련이 있으므로이 단원에서는 여러 번 강조됩니다 AWS.

Terraform을 사용하여 AWS 리소스를 프로비저닝하고 관리하는 경우 API 호출에 적절한 권한이 필요한 엔터티(사용자 또는 역할)를 대신합니다. 최소 권한을 따르지 않으면 주요 보안 위험이 발생합니다.

IAM 역할 사용

가능하면 IAM 사용자 대신 IAM 역할을 사용하여 Terraform AWS 공급자의 보안을 강화합니다. IAM 역할은 자동으로 교체되는 임시 보안 자격 증명을 제공하므로 장기 액세스 키를 관리할 필요가 없습니다. 또한 역할은 IAM 정책을 통해 정확한 액세스 제어를 제공합니다.

IAM 정책을 사용하여 최소 권한 액세스 권한 부여

IAM 정책을 신중하게 구성하여 역할과 사용자가 워크로드에 필요한 최소 권한 집합만 갖도록 합니다. 빈 정책으로 시작하고 허용된 서비스 및 작업을 반복적으로 추가합니다. 이를 수행하는 방법은 다음과 같습니다.

잘 구성된 정책은 워크로드의 책임을 완수할 수 있는 충분한 액세스 권한만 부여합니다. 작업 수준에서 작업을 정의하고 특정 리소스의 필수 APIs에 대한 호출만 허용합니다.

이 모범 사례를 따르면 영향 범위가 줄어들고 업무 분리 및 최소 권한 액세스라는 기본 보안 원칙을 따릅니다. 열기를 시작하고 나중에 액세스를 제한하는 대신 필요에 따라 엄격하고 열린 액세스를 점진적으로 시작합니다.

로컬 인증을 위한 IAM 역할 수임

Terraform을 로컬에서 실행할 때는 정적 액세스 키를 구성하지 마세요. 대신 IAM 역할을 사용하여 장기 자격 증명을 노출하지 않고 일시적으로 권한 있는 액세스 권한을 부여합니다.

먼저 필요한 최소 권한을 가진 IAM 역할을 생성하고 사용자 계정 또는 페더레이션 자격 증명에서 IAM 역할을 수임할 수 있는 신뢰 관계를 추가합니다. 이렇게 하면 역할의 임시 사용이 승인됩니다.

신뢰 관계 정책 예제:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/terraform-execution"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

그런 다음 aws sts assume-role AWS CLI 명령을 실행하여 역할에 대한 단기 자격 증명을 검색합니다. 이러한 자격 증명은 일반적으로 1시간 동안 유효합니다.

AWS CLI 명령 예제:

aws sts assume-role --role-arn arn:aws:iam::111122223333:role/terraform-execution --role-session-name terraform-session-example

명령 출력에는 AWS다음을 인증하는 데 사용할 수 있는 액세스 키, 보안 키 및 세션 토큰이 포함되어 있습니다.

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA3XFRBF535PLBIFPI4:terraform-session-example",
        "Arn": "arn:aws:sts::111122223333:assumed-role/terraform-execution/terraform-session-example"
    },
    "Credentials": {
        "SecretAccessKey": " wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": " AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE",
        "Expiration": "2024-03-15T00:05:07Z",
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE"
    }
}

AWS 공급자는 역할 수임을 자동으로 처리할 수도 있습니다.

IAM 역할을 수임하기 위한 공급자 구성 예제:

provider "aws" {
  assume_role {
    role_arn     = "arn:aws:iam::111122223333:role/terraform-execution"
    session_name = "terraform-session-example"
  }
}

이렇게 하면 Terraform 세션 기간 동안 엄격하게 승격된 권한이 부여됩니다. 임시 키는 최대 세션 기간 후에 자동으로 만료되므로 유출될 수 없습니다.

이 모범 사례의 주요 이점으로는 장기 액세스 키에 비해 보안 개선, 최소 권한을 위한 역할에 대한 세분화된 액세스 제어, 역할의 권한을 수정하여 액세스를 쉽게 취소할 수 있는 기능 등이 있습니다. 또한 IAM 역할을 사용하면 보안 암호를 스크립트 또는 디스크에 로컬로 직접 저장할 필요가 없으므로 팀 간에 Terraform 구성을 안전하게 공유할 수 있습니다.

Amazon EC2 인증에 IAM 역할 사용

Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 Terraform을 실행하는 경우 장기 보안 인증 정보를 로컬에 저장하지 마세요. 대신 IAM 역할 및 인스턴스 프로파일을 사용하여 최소 권한 권한을 자동으로 부여합니다.

먼저 최소 권한이 있는 IAM 역할을 생성하고 인스턴스 프로파일에 역할을 할당합니다. 인스턴스 프로파일을 사용하면 EC2 인스턴스가 역할에 정의된 권한을 상속할 수 있습니다. 그런 다음 해당 인스턴스 프로파일을 지정하여 인스턴스를 시작합니다. 인스턴스는 연결된 역할을 통해 인증됩니다.

Terraform 작업을 실행하기 전에 인스턴스 메타데이터에 역할이 있는지 확인하여 자격 증명이 성공적으로 상속되었는지 확인합니다.

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/iam/security-credentials/

이 접근 방식은 영구 AWS 키를 인스턴스 내의 스크립트 또는 Terraform 구성으로 하드 코딩하지 않도록 합니다. 임시 자격 증명은 인스턴스 역할 및 프로파일을 통해 Terraform에 투명하게 제공됩니다.

이 모범 사례의 주요 이점으로는 장기 자격 증명에 대한 보안 향상, 자격 증명 관리 오버헤드 감소, 개발, 테스트 및 프로덕션 환경 간의 일관성 등이 있습니다. IAM 역할 인증은 최소 권한 액세스를 적용하면서 EC2 인스턴스에서 Terraform 실행을 간소화합니다.

HCP Terraform 워크스페이스에 동적 자격 증명 사용

HCP Terraform은 HashiCorp에서 제공하는 관리형 서비스로, 팀이 Terraform을 사용하여 여러 프로젝트 및 환경에서 인프라를 프로비저닝하고 관리할 수 있도록 지원합니다. HCP Terraform에서 Terraform을 실행하는 경우 동적 자격 증명을 사용하여 AWS 인증을 간소화하고 보호합니다. Terraform은 IAM 역할 가정 없이 각 실행에서 임시 자격 증명을 자동으로 교환합니다.

더 쉬운 보안 암호 교체, 워크스페이스 간 중앙 집중식 자격 증명 관리, 최소 권한, 하드 코딩된 키 제거 등의 이점이 있습니다. 해시된 임시 키를 사용하면 수명이 긴 액세스 키에 비해 보안이 향상됩니다.

에서 IAM 역할 사용 AWS CodeBuild

에서 CodeBuild 프로젝트에 할당된 IAM 역할을 사용하여 빌드를 AWS CodeBuild실행합니다. 이렇게 하면 각 빌드가 장기 키를 사용하는 대신 역할에서 임시 자격 증명을 자동으로 상속할 수 있습니다.

HCP Terraform에서 원격으로 GitHub Actions 실행

HCP Terraform 워크스페이스에서 Terraform을 원격으로 실행하도록 GitHub Actions 워크플로를 구성합니다. GitHub 보안 암호 관리 대신 동적 보안 인증 및 원격 상태 잠금을 사용합니다.

OIDC에서 GitHub 작업 사용 및 AWS 자격 증명 작업 구성

OpenID Connect(OIDC) 표준을 사용하여 IAM을 통해 GitHub Actions 자격 증명을 페더레이션합니다. 자격 AWS 증명 구성 작업을 사용하면 장기 액세스 키 없이 GitHub 토큰을 임시 AWS 자격 증명으로 교환할 수 있습니다.

GitLab을 OIDC 및와 함께 사용 AWS CLI

OIDC 표준을 사용하여 임시 액세스를 위해 IAM을 통해 GitLab 자격 증명을 페더레이션합니다. OIDC를 사용하면 GitLab 내에서 장기 AWS 액세스 키를 직접 관리할 필요가 없습니다. 자격 증명은 just-in-time 교환되므로 보안이 향상됩니다. 또한 사용자는 IAM 역할의 권한에 따라 최소 권한 액세스 권한을 얻습니다.

레거시 자동화 도구와 함께 고유한 IAM 사용자 사용

IAM 역할 사용에 대한 기본 지원이 없는 자동화 도구 및 스크립트가 있는 경우 개별 IAM 사용자를 생성하여 프로그래밍 방식 액세스 권한을 부여할 수 있습니다. 최소 권한의 원칙은 여전히 적용됩니다. 정책 권한을 최소화하고 각 파이프라인 또는 스크립트에 대해 별도의 역할을 사용합니다. 최신 도구 또는 스크립트로 마이그레이션할 때 기본적으로 역할 지원을 시작하고 점진적으로 역할로 전환합니다.

Jenkins AWS 자격 증명 플러그인 사용

AWS Jenkins의 자격 증명 플러그인을 사용하여 중앙에서 AWS 자격 증명을 구성하고 빌드에 동적으로 주입합니다. 이렇게 하면 보안 암호를 소스 제어로 확인하지 않아도 됩니다.

최소 권한을 지속적으로 모니터링, 검증 및 최적화

시간이 지남에 따라 필요한 최소 정책을 초과할 수 있는 추가 권한이 부여될 수 있습니다. 액세스를 지속적으로 분석하여 불필요한 권한을 식별하고 제거합니다.

액세스 키 사용량을 지속적으로 모니터링

액세스 키 사용을 피할 수 없는 경우 IAM 자격 증명 보고서를 사용하여 90일이 지난 미사용 액세스 키를 찾고 사용자 계정과 시스템 역할 모두에서 비활성 키를 취소합니다. 관리자에게 활성 직원 및 시스템의 키 제거를 수동으로 확인하도록 알립니다.

키 사용을 모니터링하면 미사용 권한을 식별하고 제거할 수 있으므로 권한을 최적화하는 데 도움이 됩니다. 액세스 키 교체로이 모범 사례를 따르면 자격 증명 수명이 제한되고 최소 권한 액세스가 적용됩니다.

AWS 는 관리자에 대한 알림 및 알림을 설정하는 데 사용할 수 있는 여러 서비스와 기능을 제공합니다. 다음은 몇 가지 옵션입니다.

IAM 정책을 지속적으로 검증

IAM Access Analyzer를 사용하여 역할에 연결된 정책을 평가하고 부여된 미사용 서비스 또는 초과 작업을 식별합니다. 주기적 액세스 검토를 구현하여 정책이 현재 요구 사항과 일치하는지 수동으로 확인합니다.

기존 정책을 IAM Access Analyzer에서 생성된 정책과 비교하고 불필요한 권한을 제거합니다. 또한 사용자에게 보고서를 제공하고 유예 기간이 지나면 미사용 권한을 자동으로 취소해야 합니다. 이렇게 하면 최소한의 정책이 계속 적용됩니다.

더 이상 사용되지 않는 액세스를 선제적으로 자주 취소하면 위반 중에 위험할 수 있는 자격 증명이 최소화됩니다. 자동화는 지속 가능한 장기 자격 증명 위생 및 권한 최적화를 제공합니다. 이 모범 사례를 따르면 AWS 자격 증명 및 리소스에 대해 최소 권한을 사전에 적용하여 영향 범위를 제한할 수 있습니다.

보안 원격 상태 스토리지

원격 상태 스토리지란 Terraform이 실행 중인 시스템에 로컬로 저장하는 대신 Terraform 상태 파일을 원격으로 저장하는 것을 말합니다. 상태 파일은 Terraform에서 프로비저닝한 리소스와 메타데이터를 추적하기 때문에 매우 중요합니다.

원격 상태를 보호하지 못하면 상태 데이터 손실, 인프라 관리 불가, 의도하지 않은 리소스 삭제, 상태 파일에 존재할 수 있는 민감한 정보의 노출과 같은 심각한 문제가 발생할 수 있습니다. 따라서 프로덕션 등급 Terraform을 사용하려면 원격 상태 스토리지를 보호하는 것이 중요합니다.

암호화 및 액세스 제어 활성화

Amazon Simple Storage Service(Amazon S3) 서버 측 암호화(SSE)를 사용하여 저장 시 원격 상태를 암호화합니다.

협업 워크플로에 대한 직접 액세스 제한

이러한 지침을 따르면 민감한 리소스 속성을 보호하고 팀원의 변경 사항과의 충돌을 방지하는 데 도움이 됩니다. 암호화 및 엄격한 액세스 보호는 공격 표면을 줄이는 데 도움이 되며 협업 워크플로는 생산성을 높입니다.

사용 AWS Secrets Manager

Terraform에는 보안 암호 값을 상태 파일에 일반 텍스트로 저장하는 많은 리소스와 데이터 소스가 있습니다. 보안 암호를 상태로 저장하지 말고 AWS Secrets Manager 대신 사용하세요.

민감한 값을 수동으로 암호화하려는 대신 민감한 상태 관리에 대한 Terraform의 기본 지원을 사용합니다. 민감한 값을 출력으로 내보낼 때는 값이 민감한 것으로 표시되어야 합니다.

인프라 및 소스 코드를 지속적으로 스캔

인프라와 소스 코드를 모두 지속적으로 검사하여 보안 태세를 강화하기 위해 노출된 자격 증명이나 잘못된 구성과 같은 위험이 있는지 확인합니다. 리소스를 재구성하거나 패치하여 조사 결과를 즉시 해결합니다.

동적 스캔에 AWS 서비스 사용

Amazon Inspector, AWS Security Hub, Amazon Detective, Amazon GuardDuty와 같은 AWS 기본 도구를 사용하여 계정 및 리전 간에 프로비저닝된 인프라를 모니터링할 수 있습니다. Security Hub에서 반복 스캔을 예약하여 배포 및 구성 드리프트를 추적합니다. EC2 인스턴스, Lambda 함수, 컨테이너, S3 버킷 및 기타 리소스를 스캔합니다.

정적 분석 수행

Checkov와 같은 정적 분석기를 CI/CD 파이프라인에 직접 임베드하여 배포 전에 Terraform 구성 코드(HCL)를 스캔하고 위험을 선제적으로 식별합니다. 이렇게 하면 보안 검사가 개발 프로세스의 이전 지점(왼쪽 이동이라고 함)으로 이동하고 잘못 구성된 인프라를 방지할 수 있습니다.

프롬프트 문제 해결 보장

모든 스캔 결과에 대해 Terraform 구성을 업데이트하거나, 패치를 적용하거나, 리소스를 수동으로 적절하게 재구성하여 신속한 문제 해결을 보장합니다. 근본 원인을 해결하여 위험 수준을 낮춥니다.

인프라 스캔과 코드 스캔을 모두 사용하면 Terraform 구성, 프로비저닝된 리소스 및 애플리케이션 코드 전반에 걸쳐 계층화된 인사이트를 얻을 수 있습니다. 이렇게 하면 소프트웨어 개발 수명 주기(SDLC) 초기에 보안을 포함하면서 예방, 탐지 및 대응 제어를 통해 위험 및 규정 준수 범위를 극대화할 수 있습니다.

정책 검사 적용

HashiCorp Sentinel 정책과 같은 코드 프레임워크를 사용하여 Terraform을 사용한 인프라 프로비저닝을 위한 거버넌스 가드레일과 표준화된 템플릿을 제공합니다.

Sentinel 정책은 조직 표준 및 모범 사례에 맞게 Terraform 구성에 대한 요구 사항 또는 제한을 정의할 수 있습니다. 예를 들어 Sentinel 정책을 사용하여 다음을 수행할 수 있습니다.

정책 검사를 Terraform 구성 수명 주기에 포함하면 표준 및 아키텍처 지침을 선제적으로 적용할 수 있습니다. Sentinel은 승인되지 않은 관행을 방지하면서 개발을 가속화하는 데 도움이 되는 공유 정책 로직을 제공합니다.