1. はじめに
業務で以下のような要件あり。
- ファイルサーバ的なものを作成し、WEB経由(ID/パスワード認証あり)で、ユーザの権限に応じたフォルダ/ファイルを公開したい。
- ユーザのアクセス元のSRCIPを制限したい。
それだと「EC2にNextCloudなどのクラウドストレージソフトをインストールか、もしくはSaaSのBoxとか、、」などが想定されたが、最近(2024/12)リリースされた、「AWS Transfer Family Web Apps」が、要件にマッチするかもと思い、できることを実際に確認する。
2. やったこと
- 「AWS IAM Identity Center」にて、グループとユーザを作成する。
- 「AWS Transfer Family Web Apps」にて、Web Appsを作成し、Identity Centerで作成したグループを認証の対象として設定する。
- S3バケットを作成し、公開したいフォルダ/ファイルを作成する。
- 「S3 Access Grants」の設定で、Identity Centerで作成したグループに対して、S3バケットの特定のフォルダに対する閲覧権限を付与する。
- S3バケットにCORS設定、及びSRCIP制限のバケットポリシーを設定する。
- Identity Centerに登録されたユーザが、許可されているSRCIPからのみ、Web Appsでの認証後に、権限があるフォルダ・ファイルだけが閲覧できることを確認する。
3. 構成図
4. 予習
実際に設定を行う前に、既にトライ済の記事を読んで概要を理解する。
-
そもそも「AWS Transfer Family Web Apps」とはどういうもので、どうやって設定?
- [AWS Transfer Family web apps] S3にアクセスできるWebアプリケーションをさくっと作ってみた
-
Transfer Family web apps触ってみた
⇒ 認証付き公開WEBサーバみたいなのができて、S3バケットの中身をインターネット公開できそうということが分かった。
-
Web Appsの作成手順の中で、「S3 Access Grants」を使うらしいがそれは何?
- Amazon S3 Access Grants とは何か。何が嬉しいのか。
-
Amazon S3 Access Grants を試してみた
⇒ S3バケット・フォルダ・ファイルに対し、IDベースの認可を設定できる機能らしいということが分かった。
-
「Transfer Family Web Apps」と似た機能で「Storage Browser for S3」というのもあるけど、どう違う?
-
AWS S3ブラウジング(Transfer Family Web Apps vs. Storage Browser for S3)
⇒ 前者はノーコード、後者は多少のコーディングが必要ということで、今回はより簡単そうな前者を検証することとした。
-
AWS S3ブラウジング(Transfer Family Web Apps vs. Storage Browser for S3)
5. 手順
5.1 Identity Center でのグループ/ユーザ作成
- 本検証を行うAWSアカウント内の既存のIdentity Center アカウントインスタンス(アカウントの中で使えるIdentity Center)に、以下のグループとユーザを作成する。
グループ | ユーザ |
---|---|
dodgers | ohtani |
angels | kikuchi |
- Identity Centerの管理画面上は以下のような登録状況となる(グループdodgersの中にユーザohtaniが所属)。
5.2 Transfer Family Web Appsの作成
- Transfer Family の管理画面からWeb Appsを作成する。「ウェブアプリを作成」を選択する。
- 設定(同時接続数、アプリのタイトルとロゴ)を入力しWeb Appsを作成する。
-
Web Apps での認証の対象とするグループもしくはユーザを追加する。今回はグループ単位での追加とし、Idenity Center上のグループ「dodgers」「angels」の2つを追加する。
-
作成したWeb Appsの画面で「ユーザーとグループの割り当て」を選択し、2つのグループを選択して追加する。
-
これにより各グループのメンバーであるユーザ「ohtani」「kikuchi」での認証が可能となる。
- Web AppsのエンドポイントURLにアクセスし、Identity Center に作成済のユーザ(ohtani)でログインしてみると、以下のポータルが表示される。まだS3側で何も公開設定していないため、アクセスできるものはない状態。
5.3 S3バケット/フォルダ/ファイルの作成
- S3バケットを作成し、その中に「angels-folder」「dodgers-folder」の2つのフォルダを作成し、それぞれのフォルダに公開したいファイルを保存する。
- CORS及びバケットポリシーを後で別途設定する(この時点では空)。
5.4 S3 Access Grantsの作成
-
S3 Access Grants では、「Identity Centerのdodgersグループ所属のユーザは、S3バケット内のdodgersフォルダ配下だけを閲覧可能」を実現させるような設定を行う。
-
設定項目は以下の3段構成となっており、この3つを順番に作成する。
- S3 Access Grants インスタンス: Identity Center と連携するためにリージョン毎に1つだけ作成する必要があるもの。
- ロケーション: Access Grantsで権限設定を行いたい範囲。
- 権限: ロケーションの全体/一部に対して、誰に何の権限を与えるのかの設定。
-
まず、S3 Access Grants インスタンスを作成する。連携先として、同じリージョンにあるIdentity Centerインスタンスを選択する。
- 次にロケーションとして、今回は検証用のS3バケット(1個)を設定する。ロケーションとして定義したS3バケットにアクセスするためのIAMロール設定が必要なため、それは事前に作成しておいたものを選択する。
- IAMロールの設定内容については、公式ドキュメントの「Configure IAM roles for Transfer Family web apps」の「Create an access grants role」を参照する。権限は今回はS3FullAccessとしている。
- 最後に権限を作成する。ロケーションとして設定したS3バケットの中の「dodgers-folder」配下への読み取りアクセスを、Identity Centerの「dodgers」グループに対して許可する。
-
S3 Access Grantsインスタンス、ロケーション、権限が作成できたことを確認する(この後、angels-folderに対してangelsグループからのアクセスを許可する権限設定も追加する)。
-
この時点で、試しに dodgersグループ所属のユーザ(ohtani)で再度Web Appsにログインする。権限を付与したフォルダが表示されるようになったが、まだファイルは見れない(Network Errorとなってしまう。CORS設定が必要)。
5.5 S3バケットのCORS設定
- ロケーションとして設定したS3バケットに対してCORS設定を行う。設定内容は公式ドキュメント「Set up Cross-origin resource sharing (CORS) for your bucket」を参照。
[
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"GET",
"PUT",
"POST",
"DELETE",
"HEAD"
],
"AllowedOrigins": [
"https://webapp-xxxxxxxxxxxxxxxxxx.transfer-webapp.us-east-1.on.aws"
],
"ExposeHeaders": [
"Access-Control-Allow-Origin"
]
}
]
- 再度ユーザ(ohtani)でWeb Appsにログインすると、フォルダ内のファイルが表示され、ダウンロードも可能となる。
5.6 S3バケットのバケットポリシー設定(SRCIP制限)
- 特定のSRCIPからのみアクセス可とするため、ロケーションとして設定したS3バケットに対して、バケットポリシーを追加する。
- S3バケットを管理するIAMユーザからは無条件で全てのアクセスを許可
- SRCIP x.x.x.x/32からは読み取りアクセスのみ可(ohtaniやkikuchiがWeb Apps経由でアクセスする用)
- 上記以外のアクセスは拒否(Web Appsがアクセス時に使用するS3 Grants インスタンスに対して、S3 Full Access を許可しているため、ここで明示的にDenyを入れておく必要あり)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxxxxxxxxxxx:user/xxxxxxxxx"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::mksamba-xxxxxxxx",
"arn:aws:s3:::mksamba-xxxxxxxx/*"
]
},
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::mksamba-xxxxxxxx/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "x.x.x.x/32"
}
}
},
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::mksamba-xxxxxxxx",
"Condition": {
"IpAddress": {
"aws:SourceIp": "x.x.x.x/32"
}
}
},
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::mksamba-xxxxxxxx",
"arn:aws:s3:::mksamba-xxxxxxxx/*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::xxxxxxxxxxxx:user/xxxxxxxxx"
},
"NotIpAddress": {
"aws:SourceIp": "x.x.x.x/32"
}
}
}
]
}
- バケットポリシー設定後、許可されたIP(x.x.x.x/32)以外からユーザ(ohtani)でWeb Appsでアクセスした場合、Web Appsの認証は許可されポータルは表示されるが、フォルダ・ファイルは参照できなくなる。(Web Appsへのログイン自体ができなくなるほうがUI的には望ましいが、それはこの方法では制限できない)
6. 所感
- 今回、自分としてはこれまで使ったことがない機能が多く新鮮だった。
- それっぽい感じにはなったが、もし真剣に実利用しようとする場合、認証やファイルアクセスのログ確認や、独自ドメインの付与など、もう少し検討事項がありそう。