여기서 다루는 내용
· Intro
· 서비스 개요
· 서비스 설정 및 사용법
· AWS SFTP에서 IAM Roles와 Policies
· 마무리
Intro
안녕하십니까? GS네오텍 이기연 입니다.
Reinvent 발표에서 AWS Transfer for SFTP기능이 새로 출시되었습니다. AWS Transfer for SFTP를 사용하면 애플리케이션을 수정하거나 SFTP 서버를 관리할 필요 없이 Secure Shell File Transfer Protocol(SFTP)을 사용하는 파일 전송 워크로드를 AWS로 쉽게 이동할 수 있습니다.
이번 포스팅에서는 AWS Transfer for SFTP에 대해서 설명 드리도록 하겠습니다.
서비스 개요
AWS Transfer for SFTP는 SFTP(Secure File Transfer Protocol)를 사용하여 Amazon S3와 바로 파일을 주고 받을 수 있는 완전관리형 서비스입니다. AWS가 기존 인증 시스템과 통합할 수 있고, Amazon Route 53을 사용한 DNS 라우팅도 제공하여 파일 전송 워크플로우를 AWS Transfer for SFTP로 원활하게 마이그레이션할 수 있도록 지원하므로 고객과 파트너 또는 해당 애플리케이션을 변경할 필요가 없고 인프라를 구입하고 설정할 필요도 없습니다.
AWS Transfer for SFTP의 동작 방식은 다음과 같습니다.
Transfer for SFTP는 SFTP의 장점을 살펴보면...
- SFTP 서버 관리 불필요
매니지드 서비스로 제공되기 때문에 서버 구입과 설정 필요없이, 그냥 자신이 원하는 호스트명을 정하고, 저장할 버킷만 정하면 됩니다. 해당 설정은 콘솔이나 API로 간단하게 FTP 세팅을 할 수 있습니다.또한 Transfer for SFTP를 통해 서버를 생성하게되면 자동적으로 해당 region 내에 두개의 AZ에 생성 되므로 자동적으로 HA구성이 되고, autoscaling이 built-in되어 갑작스런 서버 부하에 대해서도 걱정할 필요가 없습니다.
- 원활한 SFTP로의 마이그레이션
AWS SFTP는 SFTP 표준과 완전히 호환되며 Active Directory, LDAP 및 기타 ID를 이용할 수 있고, Route 53 DNS를 이용한 라우팅도 가능합니다. 따라서 기존 인증 시스템, 도메인 및 호스트 이름을 변경하지 않고 SFTP 기반 워크플로우를 AWS로 쉽게 마이그레이션할 수 있습니다.
- API 기반 프로세스를 위해 S3와 통합됨
AWS SFTP는 데이터를 S3에 객체 단위로 저장하므로, AWS에서 제공하는 API 기반 데이터 처리 및 분석 워크플로우를 쉽게 사용 할 수 있습니다.
서비스 설정 및 사용법
:: 1. 서버 생성
위의 그림과 같이 SFTP 콘솔로 이동하여 Create server를 통해 SFTP서버를 생성 해줍니다.
:: 2. 서버 설정
DNS configuration
- None : Default로 생성하는 server endpoint를 사용함
- Amazon Route53 DNS alias : Route53를 통해 custom hostname을 사용 할 수 있음
- Other DNS : 기본에 사용하던 custom hostname을 사용 할 수 있음
Identity provider
- Service managed : service 내에서 user를 생성하여 IAM role을 통해 직접 자격증명을 함
- Custom : Amazon API Gateway URL을 통해 사용하던 custom identity provider를 사용 할 수 있음
Logging role
AWS SFTP에서 발생하는 put, get, delete 작업등에 대한 로그들은 CloudWatch Logs에 저장되므로, CloudWatch Logs에 접근 할 수 있는 role을 갖고 있어야합니다.
본 블로그에서는 DNS configuration으로 "None"을, Identity provider로 "Service managed"를 그리고 Logging role에는 "CloudWatchLogsFullAccess"권한을 갖고있는 role을 할당 해주었습니다. 이렇게 설정이 끝나고 Create server를 해주면 수분내에 State가 Starting 상태에서 Online 상태로 바뀌고, 사용할 수 있게 됩니다.
참고로, AWS SFTP서버에서 사용할 IAM role을 생성 후에 해당 role의 Trust relationships에 trusted entities로 "transfer.amazonaws.com"이 등록되어 있는지 확인해야합니다. 만약 등록이 되어있지 않다면, 다음과 같은 정책을 넣어주어야 합니다.
아래 3번과정의 user생성에서도 Access권한에 대한 role을 설정할텐데 이때도 마찬가지로 Trust relationships를 확인해야 합니다.
:: 3. User 생성
위의 그림에서 Endpoint를 보시면 DNS configuration을 None으로 하여 생성했기 때문에 default로 생성된 endpoint가 할당 된것을 확인 할 수 있습니다. 이제 User를 생성 해보도록 하겠습니다. Add user를 클릭 해주면 아래와 같은 화면이 나옵니다.
Username
AWS SFTP서버에 접속할때 사용할 username을 설정합니다.
Access
해당 user에게 할당 될 S3에 대한 접근 권한을 정의 합니다.
Policy
AWS SFTP에서 사용 할 수 있는 전용 Policy로써,
Scope down policy라고 불립니다. Scope down policy를 선택하면 해당 user는 role에서 설정한 S3에 대한 접근권한(permission)이 아닌 Scope down policy에 정의한 S3에 대한 접근권한(permission)을 할당받게 됩니다. 이를 이용하여, 하나의 Bucket에 여러개의 user를 생성하고, 해당 user에게 고유한 directory에만 접근할 수 있도록 설정해줄수 있습니다. 제가 직접 AWS SFTP를 사용해보면서 개인적으로 가장 중요하고 고유한 기능이라고 생각하여 Scope down policy에 대해서는 다음 섹션인 [AWS SFTP에서 IAM Roles와 Policies]에서 조금더 자세히 다루도록 하겠습니다.
- None : 아무런 Scope down policy를 사용하지 않음.
- Select a policy from IAM : IAM의 Policy에서 생성한 특정 Scope down policy를 선택할 수 있습니다.
Home directory
해당 AWS SFTP서버의 user와 연결할 S3 Bucket을 선택합니다. "Enter optional folder"부분에 path를 추가시키면 bucket의 해당 folder에 파일을 업로드 할 수 있습니다.
SSH public keys
ssh-keygen을 통해서 생성한 ssh public key를 입력해줍니다. user를 통해서 AWS SFTP서버에 접근시에는 ssh private key를 이용해서 접근하게 됩니다. ssh public/private key를 생성하는 방법은
여기를 참고하십시오.
:: 4. 서버 접근 테스트
모든 설정이 끝났으면, 이제 방금 생성한 user를 통해 위에서 생성한 AWS SFTP서버에 접근하여 작업을 해보도록 하겠습니다.
위의 그림과 같이 sftp명령을 사용하며, 위에서 user생성시에 등록한 ssh public key의 private key를 통해 해당 서버에 인증을 합니다. 그리고 "user@endpoint" 형태로 서버에 access 할 수 있습니다. 연결이 성공하면 위와 같이 Connected to "endpoint"라는 결과가 나타나고 sftp 서버에서 작업을 할 수 있게됩니다. pwd 명령을 통해 현재 directory를 확인 할 수 있습니다.
이제 sftp 서버를 통해서 S3에 파일을 업로드 해보겠습니다. 기존 sftp 서버에서 사용하던 명령어 그대로 사용 할 수 있습니다. 아래와 같이 put 명령어를 통해 S3에 자신의 Home directory로 설정한 folder에 파일을 업로드 할 수 있습니다.
S3 버킷의 해당 user에 할당된 Home directory 폴더를 확인하면, 업로드 된것을 확인 할 수 있습니다.
아래와 같이 get 명령어 및 rm 명령어를 통해 파일을 다운로드받고, 파일을 bucket에서 삭제 할 수 있습니다.
- get
- rm
:: 5. CloudWatch Logs를 통한 log 확인
AWS SFTP서버를 생성 할 떄 우리는 Logging role에 CloudWatch Logs에 대한 Full access를 주어 AWS SFTP서버에서 발생한 작업들에 대한 log들을 CloudWatch Logs에 저장하도록 하였습니다. CloudWatch Logs console로 이동하여 확인을 해보면 아래 그림과 같이 CloudWatch > Log Groups > Streams for/aws/transfer/"endpoint" 형태의 log group에 log들이 시간순으로 쌓이고 있는것을 확인 할 수 있습니다.
AWS SFTP에서 IAM Roles와 Policies
위의 Demo를 통해 간단한 설정만으로, AWS SFTP 서버를 생성하고, user를 추가하여 SFTP 서버를 사용 할 수 있었습니다. 위에서 생성한 user는 Access 권한으로 S3FullAcess Role을 갖고 있기때문에 해당 user로 SFTP통신을 하게되면, AWS SFTP 서버를 구축한 해당 계정의 모든 Bucket에 접근이 가능하고, 모든 Bucket에서 put, get, delete 등의 작업을 할 수 있습니다. 만약, 실제로 AWS SFTP서버 운영시에는 이렇게 user에게 Access role을 주게된다면 보안적으로 치명적일 수 있습니다.
그렇기 때문에 위에서 설명한 Scope down policy를 통해서 특정 user에게 자신에게 할당된 Home directory(arn:aws:s3:::[Bucket]/[folder])에만 접근하여 put, get, delete 등의 작업을 수행 할 수 있게 제한 할 수 있습니다.
먼저, AWS Transfer for SFTP에서 IAM role과 Policy의 동작방식에 대해서 알아보도록 하겠습니다. AWS SFTP 서버를 생성후 해당 서버에 user를 생성하게 됩니다. 그리고 user를 통해서 AWS SFTP 서버를 이용하게 될겁니다. 이때, SFTP 사용자를 대신하여 SFTP 서버를 작동 시키려면 SFTP 서버에 SFTP 사용자의 Amazon S3 버킷 액세스 정책에 대한 AssumeRole action이 할당되어야합니다. 이 작업을 통해 SFTP서버는 SFTP 사용자의 Trust Relationships(위에서 user 생성 과정에서 user에게 할당한 IAM role)를 상속받고 대신 파일 작업을 수행 할 수 있습니다. 다음 그림은이 역할과 정책이 어떻게 AssumeRole action으로 전환되는지 보여줍니다.
user 설정에서 [Access] 부분에 특정 IAM role을 주게 된다면, IAM policy가 IAM role에게 Assign policy to role하는 과정에서 해당 role이 갖고 있는 policy들을 할당 해주게 됩니다. 하지만 여기서 user 설정 부분에 Scope down policy를 설정 해놓았다면, 해당 policy를 IAM role에 할당을 해주게 되고 user는 IAM role에 있는 policy의 permission이 아닌 scope down policy에 있는 permission을 갖게 됩니다.
Scope down policy 설정은
여기를 참고해주세요.
Scope down policy를 사용하면 user가 Role(Trust relationships)을 통해 SFTP server에 동일한 액세스 권한을 갖지만 각각 S3 버킷의 다른 부분 (Ex : user의 해당 홈 디렉토리)에만 동일한 IAM Policy(=Scope down policy)를 통해 접근 할 수 있습니다. 쉽게 예를들어 설명하자면, user1에게 홈 디렉토리로 "Bucket/user1"이라고 지정하면 scope down policy를 통해 user1은 해당 홈 디렉토리에만 접근 하도록 할 수 있고, 동일한 scope down policy로 user2에게는 "Bucket/user2"라는 홈 디렉토리에만 접근 가능하도록 할 수 있습니다. 따라서 동일한 Policy를 여러 사용자에게보다 쉽게 적용 할 수 있으므로 Amazon S3 버킷에 대한 사용자의 액세스를 관리하기위한 IAM Role 및 Policy 관리의 오버헤드를 줄일 수 있습니다. 아래 demo를 통해 확인해보도록 하겠습니다.
1. adminuser -> Access에 S3의 접근권한을 갖고 있는 role을 할당해줌, Scope down policy : None
해당 Bucket의 모든 폴더(SFTP에서는 Home directory)에 접근이 가능한 것을 확인 할 수 있습니다.
2. user1 -> Access에 S3의 접근권한을 갖고 있는 role을 할당해줌, Scope down policy : 사용
자신의 Home directory에만 접근이 가능한 것을 확인 할 수 있습니다.
마무리
지금까지 AWS Transfer for SFTP에 대해서 알아봤습니다. 기존 SFTP서버를 사용하기 위해 직접 인프라를 구축하고 설정했던 번거로움을 AWS Transfer for SFTP를 통해서 간단한 설정만으로 SFTP서버를 생성하므로 수고를 덜 수 있고, 기존에 쓰던 SFTP서버를 그대로 Hostname 변경없이 AWS Transfer for SFTP를 통해 AWS로 마이그레이션 할 수 있게 되었습니다. 또한 AWS Transfer for SFTP는 매니지드 서비스이기 때문에, 관리 이슈도 덜 수 있습니다. 기존 SFTP를 사용하던 고객이라면 한번쯤 고려해볼만한 서비스라고 생각되네요.
감사합니다.
