AWS 기술 블로그
Amazon MWAA의 최소 권한 구성을 위한 모범 사례
이 글은 AWS Big Data Blog 에 게시된 Best practices for least privilege configuration in Amazon MWAA 을 한국어 번역 및 편집 하였습니다.
Amazon Managed Workflows for Apache Airflow(Amazon MWAA)는 AWS에서 Apache Airflow를 실행하기 위한 안전하고 관리되는 환경을 제공합니다. Airflow는 금융 및 의료와 같은 고도로 규제된 산업에서 널리 사용되고 있습니다. 이러한 분야의 고객들은 Amazon MWAA의 기본 설정보다 더 강화된 보안을 원하며, 접근 권한과 트래픽을 추가로 제한하고자 할 수 있습니다. 이 블로그에서는 이를 위한 몇 가지 권장 사례를 소개하고자 합니다.
최소 권한 원칙은 철저히 지켜야 할 기본 원칙입니다. AWS 서비스를 구성할 때는 리소스에 꼭 필요한 최소한의 권한만 부여하고, 과도하게 광범위하거나 허용적인 정책을 피하는 것이 좋습니다.
이 블로그에서는 보안 그룹, 네트워크 액세스 제어 목록(ACL) 및 가상 프라이빗 클라우드(VPC) 엔드포인트를 사용하여 네트워크 보안을 강화함으로써 Amazon MWAA 환경에 최소 권한 원칙을 적용하는 방법을 알아봅니다. 또한 Amazon MWAA 실행 및 배포 역할과 각각의 권한에 대해서도 자세히 살펴보겠습니다.
Amazon MWAA 환경이 생성되면 AWS에서 관리하는 서비스 VPC와 고객이 관리하는 VPC에 리소스가 생성됩니다. 환경 생성 시 지정된 고객의 VPC에는 Amazon Elastic Container Service(Amazon ECS) 클러스터에서 실행되는 스케줄러와 작업자를 포함하여 Airflow 환경을 실행하는 데 필요한 리소스가 배포됩니다. 이러한 클러스터는 고객 계정의 프라이빗 IP 주소를 가진 탄력적 네트워크 인터페이스(ENI)를 사용하여 VPC에 배포됩니다. 이러한 ENI들은 두개의 가용 영역에 걸쳐 프라이빗 서브넷에 분산되어 있으며, 서비스 소유 계정(프라이빗 액세스 모드인 경우)에 있는 Airflow 데이터베이스 및 웹 서버에 연결됩니다. 이러한 아키텍처는 다음 다이어그램과 같이 구성됩니다.
VPC 보안 그룹은 ENI 수준 또는 인스턴스 수준에서 네트워크 트래픽을 제어할 수 있는 가상 방화벽 역할을 합니다. 보안 그룹은 상태 저장 방식(stateful)으로 작동하는데, 이는 인바운드 트래픽이 자동으로 아웃바운드로 허용되고, 그 반대도 마찬가지라는 뜻 입니다. VPC의 기본 보안 그룹 구성은 인바운드 규칙이 없고 모든 트래픽을 허용하는 아웃바운드 규칙으로 시작합니다. 따라서, 인바운드 규칙이 없는 보안 그룹은 0.0.0.0/0 아웃바운드 규칙을 통해 허용된 트래픽을 제외한 모든 인바운드 트래픽을 차단합니다.
Amazon MWAA는 고객 VPC 내에서 두 가지 웹 서버 액세스 모드를 제공합니다. 퍼블릭과 프라이빗 모드입니다. 퍼블릭 웹 서버 모드에서는 공용 인터넷을 통해 고객 소유 VPC의 웹 서버에 접근할 수 있어야 합니다. 이를 위해서는 퍼블릭 서브넷과 NAT 게이트웨이를 사용하여 공용 인터넷으로 라우팅해야 합니다. NAT 게이트웨이는 프라이빗 서브넷의 리소스에 인터넷 액세스를 제공하는 데 사용할 수 있습니다. 프라이빗 액세스 모드에서는 Amazon MWAA 환경의 보안 그룹이 NAT 게이트웨이와의 트래픽을 허용할 필요가 없으며, VPC 내에서 적절한 권한을 가진 사용자에게만 Airflow UI에 대한 접근 권한을 부여합니다. 애플리케이션 로드 밸런서는 퍼블릭 모드에서만 프로비저닝되어 퍼블릭 웹 서버로 트래픽을 라우팅합니다. 나머지 네트워킹 구성 요소는 고객님께서 직접 프로비저닝해야 합니다.
만약 Amazon MWAA 환경이 VPC 외부의 리소스(예: 외부 데이터 소스 또는 API)와 통신해야 하는 경우, 필요한 트래픽을 허용하기 위해 적절한 보안 그룹 규칙과 라우팅을 구성해야 할 수 있습니다. 이러한 경우 일반적으로 NAT 게이트웨이나 VPN 연결을 사용하여 Amazon MWAA 환경과 외부 리소스 간의 통신을 용이하게 하고, AWS 리소스에는 VPC 엔드포인트를 사용합니다.
더 엄격한 보안 제한을 원하시는 경우, 인터넷 액세스 없이 프라이빗 라우팅을 사용하는 환경을 구성할 수 있으며, 더 세분화된 보안 그룹 규칙을 적용하고 VPC 엔드포인트 정책을 적용할 수 있습니다. 이 블로그에서는 최소 권한에 중점을 두고 있으므로 Amazon MWAA 환경에 필요한 최소 보안 요구 사항에 집중하도록 하겠습니다.
Amazon MWAA 환경에는 고객님의 VPC 환경 리소스와 연결된 보안 그룹이 있습니다. 이 보안 그룹은 데이터베이스 및 웹 서버와 통신하는 데 사용되는 인터페이스 VPC 엔드포인트에 의해 생성된 ENI에도 사용됩니다. 기본적으로 보안 그룹은 모든 인바운드 트래픽을 거부하며, 보안 그룹 규칙은 인스턴스가 네트워크 트래픽을 허용할 포트와 소스를 명시적으로 지정하는 보안 그룹 규칙을 설정해야 합니다. 최소한의 필수 설정으로, Amazon MWAA 환경은 Amazon MWAA가 소유하고 관리하는 Amazon Aurora PostgreSQL 호환 에디션 메타데이터 데이터베이스와의 양방향 트래픽을 허용해야 합니다. 이 메타데이터 데이터베이스는 작업 실행, 구성 및 모니터링을 위한 중앙 집중식 정보 소스 역할을 하는 Airflow의 중요한 구성 요소입니다. 스케줄러와 작업자 모두 작업을 조정하고 실행하는 각자의 역할을 수행하기 위해 이 데이터베이스에 접근 해야 하며, 이 데이터베이스는 TCP 포트 5432에서 수신합니다. 또한 웹 서버 트래픽은 TCP 포트 443을 통한 HTTPS로 제한될 수 있습니다. 따라서, Amazon MWAA 보안 그룹은 최소한 다음 표에 자세히 설명된 두 개의 인바운드 규칙을 반드시 포함해야 합니다.
유형 | 프로토콜 | 포트 범위 | 소스 유형 | 소스 |
사용자 지정 TCP | TCP | 5432 | 사용자 지정 | sg-xxxxx / my-mwaa-vpc-security-group |
HTTPS | TCP | 443 | 사용자 지정 | sg-xxxxx / my-mwaa-vpc-security-group |
많은 고객분은 VPC에 Amazon MWAA 작업자가 접근해야 하는 다른 AWS 리소스를 보유하고 있습니다. 이러한 리소스에 대한 네트워크 접근은 프라이빗 라우팅 구성에서 보안 그룹을 통해 허용할 수 있습니다. 만약 접근이 필요한 리소스가 MWAA와 동일한 보안 그룹 내에 있는 경우, 필요한 포트를 추가로 허용하는 인바운드 규칙을 추가하면 됩니다. 예를 들어, Amazon Redshift 클러스터가 동일한 보안 그룹 내에 있는 경우 다음과 같은 규칙을 추가할 수 있습니다.
유형 | 프로토콜 | 포트 범위 | 소스 유형 | 소스 |
사용자 지정 TCP | TCP | 5439 | 사용자 지정 | sg-xxxxx / my-mwaa-vpc-security-group |
Redshift 클러스터가 다른 보안 그룹에 있는 경우 소스를 Redshift 보안 그룹으로 변경하여 주시기 바랍니다.
유형 | 프로토콜 | 포트 범위 | 소스 유형 | 소스 |
사용자 지정 TCP | TCP | 5439 | 사용자 지정 | sg-xxxxx / redshift-security-group |
리소스가 다른 VPC에 있는 경우, 해당 VPC의 보안 그룹을 참조하기 전에 VPC 피어링을 활성화해야 합니다. 서브넷에 없는 리소스의 경우, VPC 엔드포인트는 Amazon MWAA 환경과 해당 리소스 간의 프라이빗 라우팅을 제공합니다. 예를 들어, Amazon Simple Storage Service(Amazon S3)용 VPC 엔드포인트는 향상된 보안, 개선된 성능 및 비용 절감을 제공할 수 있습니다.
네트워크 ACL은 서브넷 수준에서 인바운드 및 아웃바운드 트래픽을 허용 또는 거부 규칙을 통하여 관리할 수 있습니다. ACL은 상태 비저장(stateless)으로 작동하며, 인바운드 및 아웃바운드 규칙을 별도로 명시적으로 지정해야 합니다. VPC 네트워크의 인스턴스에서 허용되는 네트워크 트래픽 유형을 지정하는 데 사용됩니다.
모든 Amazon VPC에는 기본적으로 인바운드 및 아웃바운드 트래픽을 허용하는 기본 ACL을 가지고 있으며, 이 기본 규칙은 다음과 같습니다.
규칙 번호 | 유형 | 프로토콜 | 포트 범위 | 소스 | 허용/거부 |
100 | 모든 IPv4 트래픽 | 전체 | 전체 | 0.0.0.0/0 | 허용 |
* | 모든 IPv4 트래픽 | 전체 | 전체 | 0.0.0.0/0 | 거부 |
고객님은 이 기본 ACL 규칙을 수정하거나 새로운 사용자 지정 ACL을 생성하여 서브넷에 연결할 수 있습니다. 서브넷에는 한 번에 단 하나의 ACL만 연결할 수 있으며, 하나의 ACL을 여러 서브넷에 연결할 수 있습니다. Amazon MWAA 환경에서 최소 권한을 구현하려면 인바운드 ACL을 제한하여 메타데이터 데이터베이스와 웹 서버에서 오는 트래픽만 허용하고, 아웃바운드는 프라이빗 서브넷의 클라이언트에게만 트래픽을 허용하도록 제한할 수 있습니다. 다음 예시에서는 샘플 프라이빗 IP를 사용하고 있으며, 실제 적용 시에는 고객님의 환경에 맞는 IP 주소로 대체해야 함을 양해 부탁드립니다.
인바운드 NACL
규칙 번호 | 유형 | 프로토콜 | 포트 범위 | 소스 | 허용/거부 | 설명 |
100 | 사용자 지정 TCP | TCP | 5432 | 10.192.21.0/16 | 허용 | 프라이빗 서브넷에서 인바운드 데이터베이스 트래픽 허용 |
110 | HTTPS | TCP | 443 | 10.192.21.0/16 | 허용 | 프라이빗 서브넷에서 인바운드 HTTPS 트래픽 허용 |
* | 모든 트래픽 | 전체 | 전체 | 0.0.0.0/0 | 거부 | 이전 규칙에서 처리되지 않은 모든 인바운드 IPv4 트래픽 거부(수정 불가) |
아웃바운드 NACL
규칙 번호 | 유형 | 프로토콜 | 포트 범위 | 소스 | 허용/거부 | 설명 |
100 | 사용자 지정 TCP | TCP | 1024-65535 | 10.192.21.0/24 | 허용 | 프라이빗 서브넷의 클라이언트로 아웃바운드 반환 IPv4 트래픽 허용 |
* | 모든 트래픽 | 전체 | 전체 | 0.0.0.0/0 | 거부 | 이전 규칙에서 처리되지 않은 모든 아웃바운드 IPv4 트래픽 거부(수정 불가) |
Amazon MWAA 환경을 생성하면 VPC 내에 배포됩니다. 이를 통해 Airflow 환경의 네트워크 접근 과 보안을 효과적으로 제어할 수 있습니다. 다만, Amazon MWAA 환경에서 실행되는 작업들이 VPC 외부에 있는 다른 서비스들과 연동이 필요한 경우가 있을 수 있습니다. 예를 들어, 파일 액세스를 위한 Amazon S3, ETL(추출, 변환, 로드) 작업을 시작하기 위한 AWS Glue, 또는 데이터 웨어하우스 쿼리 실행을 위한 Amazon Redshift와 같은 다른 AWS 서비스를 사용하여 작업을 수행하는 경우 입니다. 이러한 서비스들은 VPC 외부에 있으며, Amazon MWAA 환경은 이러한 외부 AWS 서비스와 안전하고 프라이빗한 연결을 설정하기 위해 VPC 엔드포인트를 사용할 수 있습니다. Amazon MWAA에서 VPC 엔드포인트의 목적은 Amazon MWAA 환경과 VPC 내의 다른 AWS 서비스 간에 안전하고 프라이빗한 연결을 제공하는 것입니다. VPC 엔드포인트는 VPC 내에 프로비저닝되는 가상 디바이스로, MWAA 환경과 다른 AWS 서비스들을 연결해주는 다리 역할을 하여 Amazon MWAA 환경이 공용 인터넷을 통하지 않고 프라이빗 IP 주소를 사용하여 서비스와 통신할 수 있게 합니다. 이러한 아키텍처는 다음 다이어그램과 같이 구성됩니다.
VPC 엔드포인트를 사용하면 Amazon MWAA 환경의 네트워크 트래픽을 AWS 네트워크 내에서만 유지하여 공용 인터넷에 대한 노출을 줄이고 Airflow 배포의 전반적인 보안을 강화할 수 있습니다. 데이터베이스와 웹 서버를 위한 프라이빗 VPC 엔드포인트가 자동으로 생성되지만, 인터넷 접속 없이 최소 권한 환경을 만들기 위해서는 Amazon MWAA에 필요한 필수 리소스를 위한 추가적인 VPC 엔드포인트가 필요합니다. Amazon S3, Amazon Simple Queue Service(Amazon SQS), Amazon CloudWatch, 그리고 선택적으로 AWS Key Management Service(AWS KMS)를 위한 VPC 엔드포인트가 생성되어야 합니다. 자세한 내용은 프라이빗 라우팅이 있는 Amazon VPC에서 필요한 VPC 서비스 엔드포인트 생성을 참고 하여 주시기 바랍니다. 필수 서비스 외에도 Amazon Redshift, Amazon EMR 및 AWS Glue와 같은 다양한 AWS 서비스를 Amazon MWAA 워크플로우에서 실행합니다. 데이터 웨어하우스로 Amazon Redshift와 상호 작용하는 워크플로우를 위해 Airflow DAG에서 일반적으로 Redshift Operator를 사용하여 호출하는 Amazon Redshift에 연결하기 위한 VPC 엔드포인트 예제를 살펴보겠습니다. Amazon VPC 인터페이스 엔드포인트 생성에 대한 자세한 내용은 인터페이스 VPC 엔드포인트를 사용하여 AWS 서비스 액세스를 참고하여 주시면 감사하겠습니다.
Amazon Virtual Private Cloud(Amazon VPC)를 사용하여 VPC 엔드포인트를 생성하려면 다음 단계를 완료하여 주시기 바랍니다:
- Amazon VPC 콘솔에서 amazonaws.region.redshift 서비스에 대한 새 VPC 엔드포인트를 생성합니다. 여기서 region은 Amazon MWAA 환경과 Redshift 클러스터가 위치한 AWS 리전입니다. 프라이빗 DNS가 활성화되어 있는지 확인하여 주세요.
- VPC 엔드포인트 정책을 생성합니다. 이 정책은 Redshift 클러스터에 대한 접근을 Amazon MWAA 환경으로만 제한하여 다른 리소스의 무단 접근을 방지하는 데 사용할 수 있습니다. 다음의 예제 정책을 참고하여 주세요:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/YourMWAAExecutionRoleName"
]
},
"Action": [
"redshift:DescribeClusters",
"redshift:DescribeClusterParameters",
"redshift:DescribeClusterSecurityGroups",
"redshift:DescribeClusterSubnetGroups",
"redshift:DescribeEventSubscriptions",
"redshift:DescribeLoggingStatus",
"redshift:DescribeReservedNodeOfferings",
"redshift:DescribeReservedNodes",
"redshift:DescribeTableRestoreStatus",
"redshift:DescribeTags",
"redshift:GetClusterCredentials",
"redshift:ListTagsForResource",
"redshift:PurchaseReservedNodeOffering",
"redshift:ResetClusterParameterGroup",
"redshift:RestoreFromClusterSnapshot",
"redshift:RevokeClusterSecurityGroupIngress",
"redshift:RevokeSnapshotAccess",
"redshift:ViewQueriesInConsole"
],
"Resource": "arn:aws:redshift:us-east-1:123456789012:cluster/my-redshift-cluster"
}
]
}
Version
필드는 정책 언어 버전을 지정합니다.Statement
섹션에는 Redshift 클러스터에 대해 지정된 작업을 허용하는 단일 명령문이 포함되어 있습니다.Effect
필드는 Allow로 설정되어 있으며, 이는 정책이 지정된 권한을 부여한다는 의미입니다.Principal
필드는 Redshift 클러스터에 액세스할 권한이 있는 Amazon MWAA 실행 역할과 연결된 AWS Identity and Access Management(IAM) 역할을 지정합니다.Action
필드는 Amazon MWAA 실행 역할이 수행할 수 있는 특정 Redshift 작업(예: 클러스터 설명, 클러스터 자격 증명 가져오기, 스냅샷에서 복원)을 나열합니다.Resource
필드는 정책이 적용되는 Redshift 클러스터의 Amazon 리소스 이름(ARN)을 지정합니다.
- VPC 엔드포인트를 올바른 라우팅 테이블과 연결합니다. 이 라우팅 테이블은 Amazon MWAA 환경이 배포된 서브넷에서 사용해야 합니다. VPC 인터페이스 엔드포인트를 사용하는 경우, 엔드포인트를 Amazon MWAA에서 사용하는 두 개의 프라이빗 서브넷 및 보안 그룹과 연결하여 주세요.
- Amazon MWAA 환경 및 Redshift 클러스터와 연결된 보안 그룹이 서로 간에 필요한 인바운드 및 아웃바운드 트래픽을 허용하는지 확인하세요. 일반적으로 Amazon MWAA 환경의 보안 그룹에서 Redshift 포트(일반적으로 5439)에 대한 접근을 허용해야 합니다.
- Amazon MWAA 콘솔의 Admin, Connections에서 Redshift 연결 세부 정보를 업데이트하여 공개 Redshift 엔드포인트 대신 VPC 엔드포인트 주소를 사용하도록 합니다. 이렇게 하면 Amazon MWAA와 Amazon Redshift 간의 연결이 안전하고 VPC 내에서 유지되도록 보장됩니다.
Amazon MWAA 환경이 접근해야 하는 AWS 서비스에 대한 VPC 엔드포인트를 구성하면 Airflow 배포와 AWS 리소스 간에 안전하고 프라이빗하며 효율적인 통신을 제공할 수 있습니다.
앞서 언급했듯이, Amazon MWAA는 로깅을 위한 CloudWatch, DAG 및 요구 사항을 위한 Amazon S3, 메시징 미들웨어로서의 Amazon SQS, 그리고 선택적으로 암호화를 위한 AWS KMS와 같은 다양한 AWS 서비스와 통합됩니다. 이러한 다양한 서비스에 대한 VPC 엔드포인트를 생성하여 모든 트래픽이 AWS 네트워크 내에서만 유지되도록 할 수 있습니다. 이러한 엔드포인트에 대한 접근은 Ingress 소스로 Amazon MWAA 보안 그룹만 허용하여 제한할 수 있습니다. 이러한 엔드포인트 및 정책을 생성하는 방법에 대한 자세한 내용은 Amazon MWAA에서의 공유 VPC 지원 소개를 참고하여 주시기 바랍니다. Amazon MWAA 환경이 2024년 4월 2일 이후에 업데이트된 경우, AWS Fargate v1.4에서 실행되며 Amazon Elastic Container Registry(Amazon ECR)를 사용하지 않으므로 이를 위한 VPC 엔드포인트를 생성할 필요가 없습니다.
Amazon MWAA 환경을 생성하고 배포하려면 IAM 사용자 또는 역할에 적절한 권한이 부여되어야 합니다. 필요한 권한은 사용자 또는 역할에 연결된 IAM 정책을 통해 부여될 수 있습니다. Amazon MWAA 환경을 생성할 때 Airflow 작업자가 작업을 수행하기 위해 맡게 될 실행 역할을 지정할 수 있습니다. 실행 역할은 워크플로우 요구 사항에 따라 필요한 AWS 서비스 및 리소스에 접근하기 위한 필요한 권한을 가져야 합니다. IAM 역할 및 사용자에게 권한을 부여할 때 최소 권한 원칙을 따르는 것이 중요합니다. Amazon MWAA 환경 및 Airflow 워크플로우가 올바르게 작동하는 데 필요한 최소한의 권한만 부여해야 합니다.
Amazon MWAA는 사용자를 대신하여 작업을 수행하기 위해 실행 역할을 수행할 수 있는 권한이 있어야 합니다. 이를 위해 Amazon MWAA 서비스가 AssumeRole 을 할 수 있도록 신뢰 정책(trust policy)을 생성합니다. 혼동된 대리자 문제를 방지하기 위해 신뢰 정책에 조건을 추가하고 필요에 따라 AWS 계정 번호와 리전을 변경합니다. 다음은 예제 정책입니다:
서비스 연결 역할이 VPC 엔드포인트를 생성하지만, 배포자 역할은 VPC 엔드포인트를 생성하고 dry run을 수행하기 위한 권한이 필요합니다. ec2:CreateVpcEndpoint 작업을 허용하고 VPC 엔드포인트, VPC, 서브넷 및 보안 그룹에 대한 리소스 ARN을 지정함으로써 이러한 권한을 제한할 수 있습니다. 또한 aws:CalledVia 조건 키를 사용하여 airflow.amazonaws.com 서비스에 대한 접근을 제한할 수 있습니다. Amazon MWAA 환경을 생성할 때 Airflow가 다른 AWS 서비스와 상호 작용하는 데 필요한 권한을 부여하는 실행 역할을 지정해야 합니다. 와일드카드 정책을 사용하는 대신 최소한의 필요한 권한을 가진 사용자 지정 정책을 생성할 수 있습니다. 다음은 AWS 관리형 키를 사용하여 Amazon MWAA가 다양한 서비스와 상호 작용할 수 있도록 하는 실행 역할 정책의 예시입니다 : 이 정책은 AWS 관리형 키를 사용할 때 Amazon MWAA에게 CloudWatch Logs, Amazon S3, Amazon SQS 및 AWS KMS와 상호 작용하는 데 필요한 권한을 부여하며, 접근할 수 있는 리소스를 명시적으로 지정합니다. 특정 요구 사항에 따라 이 정책을 더 구체화할 수 있습니다. 다음은 KMS 고객 관리형 키를 사용하여 Amazon MWAA가 다양한 서비스와 상호 작용할 수 있도록 하는 실행 정책의 예시입니다: 고객 관리형 키를 사용하는 경우, CloudWatch Logs의 Airflow 로그에 대한 액세스를 제공하기 위해 다음 JSON 정책을 키에 연결하세요:{
"Sid": "Allow logs access",
"Effect": "Allow",
"Principal": {
"Service": "logs.{your-region}.amazonaws.com"
},
"Action": [
"kms:Encrypt*",
"kms:Decrypt*",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:Describe*"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:{your-region}:{your-account-id}:*"
}
}
}
작업자가 다른 AWS 리소스에 접근할 수 있도록 필요에 따라 실행 역할에 여러 정책을 연결할 수 있습니다. 예를 들어, Amazon EMR 접근을 활성화하는 방법을 살펴보겠습니다. 다음 예시와 같이 가장 좁은 권한을 구성하는 JSON 정책을 생성할 수 있습니다:
이 게시물에서는 Amazon MWAA에서의 최소 권한 구성에 대한 모범 사례를 논의했습니다. 이러한 접근 방식을 따르면 기능을 손상시키거나 과도하게 허용적인 정책에 의존하지 않고도 최소 권한 원칙을 준수하고 Amazon MWAA 환경 내에서 안전과 보안을 최대한 유지할 수 있습니다. 보안은 항상 최우선 순위입니다. Amazon MWAA의 보안에 대해 더 자세히 알아보려면 Amazon Managed Workflows for Apache Airflow의 보안과 Amazon MWAA의 보안 모범 사례를 참고하여 주세요.