AppStreamクライアントでADFSのURLにログインする方法

目的・やりたいこと

前の[技術検証]AppStreamで表示させるアプリの制御検証に追記しようとも思いましたが、長くなりそうなので新たに記事を追加することにしました。
最後にやったAppStreamクライアントの起動を、ADFSサーバーのURLを貼っても接続するようにしたい。

もしくは、リダイレクトしたURLからClientが起動できたらいい。
・パターン1
 ClientにURL入力→ADFS→ADログイン→AppStream起動
・パターン2
 ADFS→ADログイン→AppStream(Client起動)
ADログイン後にAppStream(Client起動)させるのが難しそうなので、パターン2はおそらく無理
というかそもそも「amazonappstream:」というプレフィックスを受け付けてなかった(https://〜 じゃないとダメ)

対象となる技術

  • AppStream 2.0
  • ADFS

背景

そもそもの背景として、ADドメイン参加したスタックからストリーミングURLを作成できないというのがあった

そもそもこのドメイン参加したスタックを作成するのが大変だったので、まずこれをドキュメント化しておきます。

1.Directory Configの作成
まずドメイン結合するための構成が必要ということで、Directory Configを作成します。


Service Account Name:ドメイン名の一部(.comとかがないもの)\adminユーザー名
OU:DC=lab,DC=localだけではダメだったので、OU=Domain Controllersも追加

2.イメージのドメイン参加
最初、Launch Image builderでイメージを作成するときのConfigure networkのオプション[Active Directory domain]で指定してドメイン参加しようとしていた。

ところがどうしてもドメイン参加できない。

それもそのはず。そういやDNSサーバをADに指定してないのにどうやってドメイン参加するのかなと思ってたら案の定・・
Amazon AppStream 2.0 で Active Directoryを利用することに対する私見

どうやらActive Directoryを利用するにあたりフリートインスタンスDNS設定はDHCPオプションセットを使う前提の様です。
DHCPオプションセットは適用範囲がVPC全体しかないため、環境によっては設定を変えることができずAppStream 2.0 ドメイン結合の採用を断念せざるを得ない可能性があります。
一応DNSサーバーの設定を変えたカスタムイメージを作ってAppStream 2.0 ドメイン結合を実現することはできましたが、これが公式にサポートされている手順かは未確認であり、オフィシャルなドキュメントを見つけることもできませんでした。

3.DNS指定したカスタムイメージの作成
そこで Image builderでまずはドメイン非参加のイメージをいったん作成し、Connectでイメージにログインして、ネットワークインターフェースのIPv4DNSサーバをADサーバのIPアドレスで指定することにしました。
問題はDNS設定変更後、そのイメージをどうやってオリジナルイメージとして保存するのか全然方法が見つからなかったが、このImage Assistantを使うことがわかった。

4.Fleetのドメイン参加
Fleet作成時に3.で作成したカスタムイメージを指定

また、オプションのActive Directory domainで今度こそDirectory Configを指定し、ドメイン参加させる。

5.Stackの作成
4.で作成したドメイン参加したFleetを指定してStackを作成
これでようやくドメイン参加したStackを作成できた

このドメイン参加したスタックからは[Create Streaming URL]をしようとすると、このようにエラーが起きる

背景がわかったところで、本題のAppStreamクライアントからADFSサーバーのURLを貼って接続する検証に入ります。

参考URL

Install the AppStream 2.0 Client And Customize the Client Experience for Your Users

検証手順

接続したいURL:https://adfs.lab.local/adfs/ls/idpinitiatedsignon.aspx

ところが参考URLに記載の通り、AppStreamクライアントはAppStream 2.0 ドメイン、または接続を有効にする DNS TXT レコードを含むドメインを含む URL にのみ接続できる。このため、このURLを入れてもまず[Connect]ボタンがアクティブにならない。

これをアクティブにする方法は3つある。

  • StartURL レジストリ値を設定して、組織のログイン ポータルの URL など、ユーザーがアクセスできるカスタム URL を指定
  • TrustedDomains レジストリ値を設定して、ユーザーがアクセスできる信頼できるドメインを指定
  • AS2TrustedDomains DNS TXT レコードを作成して、ユーザーがアクセスできる信頼できるドメインを指定

最初の2つはいずれもクライアント側のレジストリの変更が伴い、実運用で全クライアント端末のレジストリを変更させるのは現実的ではない。よって自動的に3番目の選択肢しか残りません。この方法により、レジストリの変更を回避できます。
しかもやり方もすごく簡単。Route 53のTXTレコード値に「AS2TrustedDomains=ドメイン名」と入れるだけです。

ここでは「adfs.lab.local」に接続させたいため、まずlab.localのプライベートゾーンを作成し、AppStreamクライアントを起動させるWindowsのEC2がいるVPCに関連づけます。
次に、次のようにTXTレコードを作成します。


ここで注意すべきはレコード名で、自分は最初「adfs.lab.local」と入れていたため、TXTを問い合わせてもなぜかSOXが返ってくる状態でした。
(最初WireSharkで見てましたが、あまりにわかりづらいのでここは素直にコマンドプロンプトで普通に問い合わせた方が早いです)

C:\Users\Administrator>nslookup -type=TXT lab.local
サーバー:  ip-10-0-0-2.ap-northeast-1.compute.internal
Address:  10.0.0.2

lab.local
        primary name server = ns-1536.awsdns-00.co.uk
        responsible mail addr = awsdns-hostmaster.amazon.com
        serial  = 1
        refresh = 7200 (2 hours)
        retry   = 900 (15 mins)
        expire  = 1209600 (14 days)
        default TTL = 86400 (1 day)

C:\Users\Administrator>nslookup -type=TXT adfs.lab.local
サーバー:  ip-10-0-0-2.ap-northeast-1.compute.internal
Address:  10.0.0.2

権限のない回答:
adfs.lab.local  text =

        "AS2TrustedDomains=adfs.lab.local"

adfs.lab.localを問い合わせてTXTレコードが返ってきていますが、そうではなくlab.localを問い合わせてTXTレコードが返ってくるようにしないとダメ
なのでレコード名の入力欄は空欄(=lab.local)にしないとダメ
こうなるのが正解

C:\Users\Administrator>nslookup -type=TXT lab.local
サーバー:  ip-10-0-0-2.ap-northeast-1.compute.internal
Address:  10.0.0.2

権限のない回答:
lab.local       text =

        "AS2TrustedDomains=adfs.lab.local"

こうすることで、目的のURLを入れてようやく[Connect]ボタンがアクティブになるところまでいきました。

実際は接続させてもこのような接続エラーが出てしまうため、おそらく自己署名でhttps接続してるのが原因かなと思う。

最初、AppStreamに繋がるURLじゃないとクライアントから接続拒否される仕様なのかなとも思ったが、実際「amazon.co.jp」をプライベートゾーンで作成してみたら普通にアマゾンショップが開いたので

所要時間

30分
自分はレコード名の指定をミスってハマりましたが、慣れてる人ならこのくらいの時間で終わると思います。

ユースケース

ADFSへの接続をAppStreamクライアント経由にしたい場合

ADFSとAppStreamの連携検証

目的・やりたいこと

Appstream でオンプレADと連携してログインできるようにする
→Appstream とオンプレADの間にADFSサーバを立てる必要がある
→手順を用意してほしい

オンプレADにて必要な作業をまず報告

  • ADFSがドメインに参加するためのADユーザーアカウント(Domain Admins権限)
  • SSL 証明書
  • LDAPを使っていれば389、LDAPSなら636ポート、88番と49668番ポートをAD側で開けてもらう

 対象となる技術

  • AppStream 2.0
  • ADFS
  • AD

 条件(導入にあたって前提事項)

・利便性上、各EC2のWindowsサーバーでそれぞれWindows Defender FirewallIE Enhanced Security ConfigurationをOffにしています。検証環境ではこの無効化は推奨

 参考URL

  1. Amazon AppStream 2.0 & ADFS Integration (Korean)
  2. Amazon AppStream 2.0 の ID フェデレーションを AD FS 3.0 で実現する
  3. App stream 2.0 & AWS console authentications with Active Directory Federation Services (ADFS) using SAML
  4. Active Direcory on AWS~Active Directory導入編①~(③まであり、図が豊富で大変丁寧で参考になりました)
  5. [アップデート] AppStream 2.0 で SAML 2.0 Federated User を利用する際にアプリケーションの選択ができる様になりました

 注意事項

  • ADユーザーのメールアドレスはちゃんと記入する
  • AD連携する上で色々ポートを開ける必要があるが、このチュートリアルでは10.0.0.0/16 0-65535という強引な開け方をしています(セキュリティ上は推奨されません)
  • ADFSにホスト名でWeb URLアクセスするために、ローカルのMacのhostsファイルを以下のようにいじってますが、ラボが終わったら消しておく(残しておいても害はない)
$ cat /private/etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost
54.178.106.174  adfs.lab.local

(このグローバルIPは該当EC2の起動の度にころころ変わるので注意!)

 作業の流れ

 概要図

 事前作業

 検証手順

1.の韓国版ワークショップが実によくできていて、図が豊富で大変丁寧なつくりなので、素人でもうまくいきます。基本的にこの通りにやっていけばOK
なので以下では手順を逐一載せず、ポイントとなる部分だけを抜粋してピックアップしました
次点で3.もよくできてはいるが、ロールやグループのプレフィックス周りの記載のところで意味がわからなく複雑で挫折
ちなみにちょいちょい混じる韓国語がうざかったので、ChromeのDeepL拡張機能を入れると、選択右クリックで部分翻訳してました。

  • ドメインに参加させるEC2のDNSにAD EC2のIPを入れるのだが、このとき名前解決ができるよう、AD EC2のSGにDNSUDP)からの許可を入れるのを忘れないように

     

  • 途中で出てくるサービス アカウントは、「Administrator/AD on EC2にログインするときのパスワード」であることに注意

  • SPN サービス アカウントを手動で設定

PS C:\Users\Administrator.NOZAKI2> Setspn -a host/localhost Administrator
ドメイン DC=nozaki2,DC=com を確認しています

CN=Administrator,CN=Users,DC=nozaki2,DC=com の ServicePrincipalNames を登録しています
        host/localhost
更新されたオブジェクト

ADサーバーでSPNの登録はしなくていいんだろうか?

  • 今回作成したIDプロバイダーのARNは「arn:aws:iam::************:saml-provider/nozaki-ADFS-AppStream」

  • この三つのポリシーを追加

     

  • ログインさせるユーザーはADFSロールグループのメンバーにする

     

  • ADFS RelayState Generatorなんてものがあるとは知らなかった

 ハマったところ

  • 不明なエラー

ログイン前に以下のようなMS7012の不明なエラーが出る場合は、ここを参考にPowerShellコマンドを実行してください。

PS C:\Users\Administrator> Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
  • ログイン後のエラー

URL(https://adfs.lab.local/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3Dhttps%253A%252F%252Fsignin.aws.amazon.com%252Fsaml%26RelayState%3Dhttps%253A%252F%252Fappstream2.ap-northeast-1.aws.amazon.com%252Fsaml%253Fstack%253Dnozakilabstack%2526accountId%253D************)
でログインしようとしたところ、以下のRoleSessionName is required in AuthnResponse (Service: AWSSecurityTokenV20111201; Status Code: 400; Error Code: InvalidIdentityTokenというエラーが

 

ググってみたところ、どうもログインしようとしているユーザーの属性に問題があるらしい

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/troubleshoot_saml.html#troubleshoot_saml_missing-rolesessionname

このエラーは、ID プロバイダーからの SAML レスポンスに、Name が https://aws.amazon.com/SAML/Attributes/RoleSessionName に設定された属性が含まれない場合に発生することがあります。属性値は、ユーザーの ID で、通常は ID または E メールアドレスです。

https://help.duo.com/s/article/4045?language=en_US

ISSUE
You encounter "Error: RoleSessionName is required in AuthnResponse (Service: AWSSecurityTokenService; Status Code: 400; Error Code: InvalidIdentityToken)" when protecting AWS with Duo Access Gateway (DAG).
RESOLUTION
Ensure that the user account in AD has the following attributes filled out:
distinguishedName
mail
sAMAccountName
userPrincipalName

ADに入って該当のtest01ユーザーの属性を見たところ、案の定eメール欄が空・・

 

ADFSのSAML連携で実はメールアドレス属性ってかなり大事です
これにちゃんと「test01@lab.local」と入れたところ、無事AppStreamにログイン成功

 

チュートリアルのこの部分をすっかり忘れてました。

 追加課題(短縮URL

そもそもURL(https://adfs.lab.local/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3Dhttps%253A%252F%252Fsignin.aws.amazon.com%252Fsaml%26RelayState%3Dhttps%253A%252F%252Fappstream2.ap-northeast-1.aws.amazon.com%252Fsaml%253Fstack%253Dnozakilabstack%2526accountId%253D************) が長すぎる!というのがある
これをなんとか短縮できる方法があるらしい。それが参考サイト3.の後半(We need to enable Relay state by adding the below line in the config file under the section of <microsoft.identityServer.web>から)で説明されていた。

1.まずADFSサーバーの C:\Windows\ADFS\Microsoft.IdentityServer.Servicehost.exe.config を開く
ただし、自分の場合はADFSサービスが使用しているとかでこのファイルを編集しても上書きできなかったので、いったん以下でサービスを停止しました。

net stop adfssrv

2.該当箇所に以下を追加

<useRelayStateForIdpInitiatedSignOn enabled=”true” />

3.ファイルを上書きしたらサービス再開

net start adfssrv

4.ここで既存のRelying Party Trustsである「App Stream」の名前を「AWS console」としたものをもう1セットそっくりそのまま作ります。

ただし、Identifierは一意でなければならないため、既存のApp Streamの識別子は適当に、AWS consoleに以下の二つをセットしてあります。
https://signin.aws.amazon.com/saml
urn:amazon:webservices

5.「App Stream」の方のデフォルトのエンドポイントを編集し、TrustedURL にスタック エンドポイント URL を追加します。
「信頼されたURLを既定として設定する」にチェックを入れ、「信頼されたURL」に以下を入力
https://appstream2.ap-northeast-1.aws.amazon.com/saml?stack=nozakilabstack&accountId=************

 

6.ADFS サインオン ページを使用して AWS コンソールとアプリ ストリームにログインします。
https://adfs.lab.local/adfs/ls/idpinitiatedsignon.aspx

7.最初にAWS consoleにサインイン

 

8.AWSにログイン確認後、今度はもう一つタブを開いて「App Stream」にサインイン

 

9.無事AppStreamにログイン成功!

 

 所要時間

3時間
ワークショップでは5時間とあるが、非常にわかりやすくてすいすい進むので、慣れてる人ならもっと早く終わりそう

 ユースケース

RDPの代わりにAppStreamでデスクトップ接続したい場合(RDPの代わり)

AppStreamで表示させるアプリの制御検証

目的・やりたいこと

ADのグループ情報から、AppStreamで表示させるアプリの制御を行う
例)adminグループに属する人はFirefoxが表示される。userグループに属する人はEdgeが表示される。 
ていう感じでユーザのグループ毎に出し分けができるか、とその手順
AppstreamでADグループ情報から利用アプリを制限する方法

 対象となる技術

  • AppStream 2.0
  • ADFS
  • AD

 条件(導入にあたって前提事項)

 参考URL

  1. サードパーティーの SAML 2.0 アイデンティティプロバイダーを使用した属性ベースのアプリケーションの使用権限
  2. [アップデート] AppStream 2.0 で SAML 2.0 Federated User を利用する際にアプリケーションの選択ができる様になりました
  3. Enabling Identity Federation with AD FS 3.0 and Amazon AppStream 2.0

 注意事項

  • RelayState URLをいつも使っているChromeなどのブラウザで打つと、制限されたAWSアカウントでマネジメントコンソールにログインしてしまうため、いざ実際にAWSの設定をしたいときに不便です。Firefoxなど別のブラウザで、かつログインユーザーを毎回選択したいためプライベートウインドウを使いましょう
  • ADFSにホスト名でWeb URLアクセスするために、ローカルのMacのhostsファイルを以下のようにいじってますが、ラボが終わったら消しておく(残しておいても害はない)
$ cat /private/etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost
54.178.106.174  adfs.lab.local

 作業の流れ

 概要図

 事前作業

 検証手順

大きく分けて、

  • AD側のグループ設定
  • AWS側の設定
  • IDPであるADFS側の設定

が必要になります。

 AD側のグループ設定

例えばユーザーadminには「admin2」というグループを作って所属させ、ついでにAWSロールグループにも所属させる。

ちなみにadminというグループは既存のAdministratorsというグループと被るからとかで作成できませんでした。それでいて後に説明するユーザーのグループでは検索できないので注意

ユーザーtest01には「user」というグループを作り、そこに所属させる。

 AWS側の設定

AppStream StackのApplication Entitlementsで設定します。

admini2グループにはnotepad等(なんで全アプリ使わせないの?というツッコミは置いといて)を使用させる。

userグループにはfirefoxを使用させる。

前回作成したADFS-roleの信頼ポリシーで以下の「"sts:TagSession"」を追加

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::************:saml-provider/ADFS01"
            },
            "Action": [
                "sts:AssumeRoleWithSAML",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "SAML:aud": "https://signin.aws.amazon.com/saml"
                }
            }
        }
    ]
}

 IDPであるADFS側の設定

ここが苦労しました。IDPにAzure ADを使った場合の設定方法は検索するとよく出てくるのだが、ADFSを使うケースは珍しいのか出てこないので、自分で考える必要がありました。
まず、スタートから[Windows Administrative Tools] > [AD FS Management]を選択してADFS管理を起動します。

その際、もしこのようなエラーが出た場合

ADFSサービスが停止しているため、起動させます。

Relying Party Trusts > App Streamから右クリックでEdit Claim Issuance Policyを選択

Add RuleでSend LDAP Attributes as Claimsを選択

最初に考えたのが、LDAP属性にあるToken-Groups(所属グループのリスト)をそのまま使うこと

ところがこれだとSAMLで以下のように出力され、groupsが複数あるせいかどうしてもAttribute mappingが効かない。

<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag: groups">
    <AttributeValue>Domain Admins</AttributeValue>
    <AttributeValue>Domain Users</AttributeValue>
    <AttributeValue>AWS-************-ADFS-role</AttributeValue>
    <AttributeValue>user</AttributeValue>
</Attribute>

それもそのはず。Use Amazon AppStream 2.0 application entitlements with Azure ADに以下の記載があった。

各ユーザーは、いずれかのグループのメンバーのみである必要があります。ユーザーが両方のグループのメンバーである場合、「応答には無効なプリンシパル タグ値が含まれています。」というエラーが表示されます。ID プロバイダーがサポートしている場合は、グループごとにコロンで区切られた値を返すことができます。

「ID プロバイダーがサポートしている場合」ってことはADFSが対応してればいけるってこと?
でも記述に従ってこのように書いてもダメ。ADFSはこの記載方法に対応してないっぽい

例えば以下のような所属部署とかだとうまくいった

<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:department">
      <AttributeValue>pmo</AttributeValue>
</Attribute>

そこでどうしたかというと、グループメンバーシップを要求として送信することにしました。

以下のように設定


ユーザーのグループ:[参照]をクリックしてADにアクセスして実際のグループを選択します。
出力方向の要求の種類:これがよくわからなかったんですが、参考URL2.で

今回はAzure ADユーザーの所属グループに応じて利用アプリケーションを切り替えたいので https://aws.amazon.com/SAML/Attributes/PrincipalTag:groups 属性に対するクレームを追加します。

とあったので、このURLをどっかで使うんだろうなあとは思ってたんですが、どうもこの値がSAMLのAttribute Nameに設定されるらしい
出力方向の要求の値:SAMLのAttributeValueに来る値。ここは普通に「user」グループを使ってほしいのでそのまま「user」と記載

こうすることで、SAMLで以下の属性がAWSに渡されるようになった。

<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag: groups">
    <AttributeValue>user</AttributeValue>
</Attribute>

これでようやく検証できる準備設定が終わったので、いよいよ検証開始

1.Firefoxのプライベートウインドウで以下URLを入力

https://adfs.lab.local/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3Dhttps%253A%252F%252Fsignin.aws.amazon.com%252Fsaml%26RelayState%3Dhttps%253A%252F%252Fappstream2.ap-northeast-1.aws.amazon.com%252Fsaml%253Fstack%253DnozakiStack%2526accountId%253D532152701269

2.まずはadminでログイン

設定想定通りnotepad等が表示

3.次にtest01でログイン
設定想定通りfirefox等が表示

これでユーザーの所属ADグループによって表示させるアプリケーションを制御する検証ができました!

(追加検証1)

 AppStreamへのアクセスをAppStreamクライアントにリダイレクトする検証

ストリーミングセッションをウェブブラウザから AppStream 2.0 クライアントにリダイレクトするに従い、AppStreamクライアント経由でAppStreamにアクセスするという検証もしてみました。

まずはAmazon AppStream 2.0 の Workshop をやってみたに従い、AppStream 2.0クライアントのインストール
といってもWindowsマシンで https://clients.amazonappstream.com/ からクライアントをダウンロードしてインストールするだけ

次にクライアントにリダイレクトさせるURL?の生成
最初ここの意味がさっぱりわからなかったんですが

ストリーミング URL にカスタム AppStream 2.0 クライアントハンドラの次のプレフィックスを追加します: amazonappstream:

プレフィックスとストリーミング URL は、一緒に次のようにフォーマットされます。

amazonappstream:base64encoded(streamingURL)

chatgpt先生に聞いたらこういうことらしい(さすが

ストリーミングURLに"amazonappstream:"というプレフィックスを追加する必要があります。また、ストリーミングURL自体は、base64エンコードされた形式でフォーマットされます。

例えば、ストリーミングURLが"https://example.com/stream" の場合、生成されるURLは"amazonappstream:aHR0cHM6Ly9leGFtcGxlLmNvbS9zdHJlYW0="となります(base64エンコードされた形式)。

スタックからストリーミングURLを作成

https://appstream2.ap-northeast-1.aws.amazon.com/authenticate?parameters=eyJ0eXBlIjoiRU5EX1VTRVIiLCJleHBpcmVzIjoiMTY4Njg5NzIxNSIsImF3c0FjY291bnRJZCI6IjUzMjE1MjcwMTI2OSIsInVzZXJJZCI6InRlc3QwMSIsImNhdGFsb2dTb3VyY2UiOiJzdGFjay9ub3pha2lTdGFjayIsImZsZWV0UmVmIjoiZmxlZXQvbm96YWtpU3RhY2stZmxlZXQiLCJhcHBsaWNhdGlvbklkIjoiIiwidXNlckNvbnRleHQiOiIiLCJtYXhVc2VyRHVyYXRpb25JblNlY3MiOiI1NzYwMCJ9&signature=FcFtibcperA1wm6FTlDftibst9ttjzIuDXSeGPgLWl0%3D

これをbase64エンコードして生成された文字列をamazonappstream:の後に繋げる

amazonappstream:aHR0cHM6Ly9hcHBzdHJlYW0yLmFwLW5vcnRoZWFzdC0xLmF3cy5hbWF6b24uY29tL2F1dGhlbnRpY2F0ZT9wYXJhbWV0ZXJzPWV5SjBlWEJsSWpvaVJVNUVYMVZUUlZJaUxDSmxlSEJwY21Weklqb2lNVFk0TmpnNU9UZ3pNaUlzSW1GM2MwRmpZMjkxYm5SSlpDSTZJalV6TWpFMU1qY3dNVEkyT1NJc0luVnpaWEpKWkNJNkluUmxjM1F3TVVCc1lXSXViRzlqWVd3aUxDSmpZWFJoYkc5blUyOTFjbU5sSWpvaWMzUmhZMnN2Ym05NllXdHBVM1JoWTJzaUxDSm1iR1ZsZEZKbFppSTZJbVpzWldWMEwyNXZlbUZyYVZOMFlXTnJMV1pzWldWMElpd2lZWEJ3YkdsallYUnBiMjVKWkNJNklpSXNJblZ6WlhKRGIyNTBaWGgwSWpvaUlpd2liV0Y0VlhObGNrUjFjbUYwYVc5dVNXNVRaV056SWpvaU5UYzJNREFpZlElM0QlM0Qmc2lnbmF0dXJlPXRmbDNJREQlMkZ4dkFLY2YwUW9hMEdlRTZaR1pTZXJJZVZEeFhtVFJHb1MzWSUzRA==

これをAppStreamクライアントが入っているWindowsのブラウザ欄に入力すると、画像のような表示が出るので、「Amazon AppStream 2.0を開く」でAppStreamクライアントが起動してAppStreamにアクセスしに行きます。

AppStreamの全アプリケーションが表示

 

(追加検証2)

 SAML 2.0 マルチスタック アプリケーション カタログ

URLにスタック名が入っていると色々と不都合なこともあります。1URL1スタック固定になっているので、スタックごとにURLを作成する必要がある。
そこで、SAML 2.0 Multi-Stack Application Catalogによると、単一のリレー状態 URL から複数のスタックへのアクセスを有効にするマルチスタック アプリケーション カタログという機能があるそうなので試してみました。

1.次のように、スタック名パラメータをリレー状態 URL から削除します。
https://appstream2.ap-northeast-1.aws.amazon.com/saml?stack=nozakilabstack&accountId=*************

https://appstream2.ap-northeast-1.aws.amazon.com/saml?accountId=************

これをリレーステートURLで書くと次のようになります。
https://adfs.lab.local/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3Dhttps%253A%252F%252Fsignin.aws.amazon.com%252Fsaml%26RelayState%3Dhttps%253A%252F%252Fappstream2.ap-northeast-1.aws.amazon.com%252Fsaml%253FaccountId%253D************
(長すぎてわかりづらいですが、一応スタック名が消えてます)

2.IAMポリシーの変更
ドキュメントには以下の重要なことがノートとして書かれてます。

SAML 2.0 マルチスタック アプリケーション カタログを使用するには、SAML 2.0 フェデレーション IAM ロールのインライン ポリシーを設定する必要があります。詳細については、 「ステップ 3: IAM ロールのインライン ポリシーを埋め込む」を参照してください。

そしてそのリンク先には以下の超重要なことが(オプション)として書かれています。

SAML 2.0 マルチスタック アプリケーション カタログでサードパーティSAML 2.0 ID プロバイダーを使用して属性ベースのアプリケーション資格を使用する予定の場合、IAM ロール インライン ポリシーのリソースは "Resource": "arn:aws:appstream:REGION-CODE:ACCOUNT-ID-WITHOUT-HYPHENS:stack/*"である必要があります。

これ要はこのロールのポリシーにある

"Resource": "arn: aws:appstream:ap-northeast-1:************:stack/nozakilabstack" のnozakilabstack固定じゃなくて * にしろってだけの話
こうしないとログイン時に「Unable to authorize the session.」といったエラーが出てます。このエラーの対処法もちゃんとAmazon AppStream 2.0 の ID フェデレーションを AD FS 3.0 で実現するの最後の方のとラブルシューティングに載ってます。

ポリシーが無効
Unable to authorize the session. (Error Code: INVALID_AUTH_POLICY);Status Code:401
このエラーメッセージは、IAM ポリシーで AppStream 2.0 へのアクセスが許可されていない時に出る場合があります。

3.先ほどのURLを叩いてログイン

アプリケーション資格が 1 つ以上のアプリケーションとユーザーに一致したすべてのスタックが表示されます。ユーザーがカタログを選択すると、アプリケーションの資格には、ユーザーが使用する資格のあるアプリケーションのみが表示されます。

 所要時間

1時間
自分はADFSでの要求発行ポリシー変換規則がわからなくてはまりましたが、慣れてる人ならもっと早く終わりそう

 ユースケース

利用者の権限によって使用できるアプリを分けたい場合

ADFSをSAML IdPとしてCognitoユーザープールと連携してみた

サービス概要

ADFSをSAML IdPとしてCognitoユーザープールと連携

 目的・やりたいこと

Cognitoは、外部IdPと連携してサインインできる。現在ADFSを使用しているため、これをSAML IdPとしてCognitoユーザープールと連携する環境を作成してみました。

 対象となる技術

  • Cognito
  • IdP

 条件(導入にあたって前提事項)

・ADFS、AD、Cognitoユーザープールは作成済みとします。ここではそういったものの一から作成を説明しません。既にあるものとして、あくまで連携するのに必要な手順と、連携を検証します。

 参考URL

 作業の流れ

 概要図

 事前作業

Cognitoドメインを作成するのに、本物のドメインが必要になるため、自分はお名前.comでnozaki.comを無料で取得しました(1年後などに自動更新されて課金されない要注意。クレカ番号を登録しておかなければ大丈夫だと思います)

 検証手順

  1. Cognitoドメインを作成

[アプリケーションの統合]タブからドメインのアクションで[Cognitoドメインの作成]を選択します。

 

ここではこのように登録済みの本当のドメインを入れないと進められないので注意

 

2.ADFSで証明書利用者信頼を追加

  • 「要求に対応する」を選択

     

  • 「証明書利用者についてのデータを手動で入力する」を選択

  • 表示名は適当(「ad1」としました)

  • 発行者、サブジェクト、有効開始日、有効期限などはそのまま「次へ」

  • SAML 2.0 WebSSO プロトコルのサポートを有効にする」の「証明書利用者SAML 2.0 SSOサービスのURL」にCognitoユーザープールの作成時に作ったCognitoドメインを指定したエンドポイント(https://Cognitoドメイン.auth.ap-northeast-1.amazoncognito.com/saml2/idpresponse)を入力します。ここでは「nozaki.com」ではなく「nozaki」がドメイン部分に入ることに注意
    https://nozaki.auth.ap-northeast-1.amazoncognito.com/saml2/idpresponse

     

  • 証明書利用者信頼の識別子(urn:amazon:cognito:sp:ユーザープールID)を追加

     

     

  • アクセス制御ポリシーは「すべてのユーザーを許可」を選択

  • あとはそのまま進めて完了

3.ADFSで要求規則(クレームルール)を2つ作成

  • 一つはメールアドレス

     

  • もう一つは名前ID

4.メタデータの取得
これがURLがよくわからなくて苦労しました。https://AdminPortal_endpoint/FederationMetadata/2007-06/FederationMetadata.xml という形式になるらしいのですが、AdminPortal_endpointのところがよくわからず
結局、ADFSにログインするときに使っているいつものドメイン「adfs1.aws-test-dk.com」を使って、
https://adfs1.aws-test-dk.com/FederationMetadata/2007-06/FederationMetadata.xml
から取得しました。これを入れるとセキュリティの警告が出ますが、押し進めると「FederationMetadata.xml」がダウンロードできます。

5.CognitoユーザープールでSAML IdP設定

6.アプリクライアントのホストされた UIを設定

  • [アプリケーションの統合]タブからアプリケーションクライアント(ここではexamplecorp_saas_app)を選択

     

  • ホストされた UI を編集
    「許可されているコールバック URL」には適当にAWSのURLを入力しときました。
    IDプロバイダーには先ほどの「ad1」を選択

     

OAuth 2.0許可タイプでハマりました。最初Implicit grant(暗黙的な付与)のみを許可していたところ、ログイン時にどうしても「An error was encountered with the requested page unauthorized_client」に遭遇してログインできなかった。そこで、「認証コード付与」も許可したところ、何事もなかったかのように無事ログインできました。
OIDCスコープはEメールとOpenIDのみ

7.テストADユーザーの作成
最後にADの「Active Directory ユーザーコンピューター」でログイン用のユーザー「ad1」を作成します。
Administratorsグループの追加と、メールアドレス設定を忘れないように

8.実際にアクセス!
ではここでようやくアクセスできます。URLは以下
https://nozaki.auth.ap-northeast-1.amazoncognito.com/login?client_id=64edch5n5jgaaalolmbadessp4&response_type=code&scope=email+openid&redirect_uri=https://aws.amazon.com/jp

するとこのようにユーザーを選択する画面に


「ad1」を選択すると、無事ADFSのログイン画面にリダイレクトされました。

 所要時間

1時間

 ユースケース

ADFSなどIdPにCognito認証を噛ませたい場合

AWSの生成系AI Amazon Bedrockの使い方

Amazon Bedrockとは?

今話題のAmazon Bedrockとは、Amazonや主要なAI企業が提供する基盤モデル(FM)をAPIを通じて利用できるようにする完全マネージド型サービスです。FMとは、テキスト、コード、画像、音声などのさまざまな形式のデータを処理できる大規模な言語モデルです。

つまり、AWSのマネジメントコンソールで生成系AIを試せるサービスです。

ちなみにbedrockという英単語は、「基盤、根底、根幹、根本(原理)、基礎的事実」という意味

前提

今回はあくまでBedrockをAWSマネジメントコンソール上で動かすところまでを紹介する初心者用のものであり、それ以上の活用方法は扱いません。

使い方

現在、Bedrockは以下の5つのリージョンに対応しています。

 

ですが、現時点で東京リージョンでは対応しているモデルが非常に少なく、まともに使えません。

 

そこで今回はバージニア北部を選択しています。

 

ご覧のようにモデルを選択していない初期の状態だと、Chatも利用できません。

 

このため、モデルを要求する必要があります。

Model accessメニューをクリックし、右上の[Edit]

どうせならすべて利用したいのですべて選択して、[Save changes]

 

これでモデルアクセスが送られました。


しばらくすると、「Access granted」になります。

 

これでモデルが利用できるようになったので、次の3つのメニュー(Chat、Text、Image)が利用できるようになります。

 

1. Chatを試してみる

先ほどより選べるモデルのメニューが増えており、Base Modelsが追加されています。

 

現時点ではAI21 Labsだけが利用できるようです。このMidとUltraの違いは何でしょうか。

 

Base modelsのメニューで両者の違いの記載があるところで翻訳してみました。

Midは手頃な価格であらゆる言語理解に適用、Ultraは質問応答、要約、長文コピーの生成、高度な情報抽出など、複雑な言語の生成向けという使い分けのようです。

ただ両者の違いはあまり感じませんでした。

・Mid

・Ultra

 

連続で行けるか?

AWSの主なサービスを挙げてきたので、他にあるか?と聞いたところ、このchatでできる一般的なサービスを挙げてしまいました。連続では効かないようです。

 

2. Textを試してみる

こちらはChatと似ているが、何行にも渡る長文用かな?例えばこんな感じ

 

3. Imageを試してみる

こちらはモデルを現時点では選択できず、Stability AIで固定

まだ日本語だと精度はいまいち

英語だとバッチリ

 

気になる料金は?

今回は特にProvisioned throughputなどは使わず、標準のオンデマンドで使いました。これは時間ベースの契約ではなく、使用した分だけ課金されます。テキスト生成モデルの場合、処理されるすべての入力トークンと生成されるすべての出力トークンに対して料金が発生します。イメージ生成モデルの場合、生成されるイメージごとに料金が発生します。  

以下に今回使ったものを挙げておきます。

 

・AI21 Labs

AI21 models Price for 1000 input tokens Price for 1000 output tokens

Jurassic-2 Mid

$0.0125

$0.0125

Jurassic-2 Ultra

$0.0188

$0.0188

・Stability AI

Stability AI Model Image Resolution Standard quality (<51 steps) Premium quality (>51 steps)

SDXL0.8

512x512 or smaller

$0.018 per image

$0.036 per image

Larger than 512x512

$0.036 per image

$0.072 per image

 

トークンとは、いくつかの文字で構成され、モデルがユーザー入力を理解し、結果の生成を促すために学習する基本単位を指します。イメージ的には単語ベースに近いですが、モデルごとに採用している手法が異なるので必ずしも単語ベースとは限りません。

CognitoとALBの連携検証

目的・やりたいこと

Cognito検証環境でALB+Cognito構築し、ALB配下のEC2で作成したWebサイトを見に行くときに、Cognito認証+MFA認証ができるようにする

 対象者

WebサイトにCognito認証を掛けてセキュリティを向上させたいケース

 対象となる技術

  • Cognito
  • ALB
  • MFA

 条件(導入にあたって前提事項)

  • Webサイトは構築済み
  • HTTPSページもオレオレ証明書を使って構築済み(Cognitoのユーザー認証はHTTPSリスナーでのみサポートされているため、HTTPS化は必須)
  • ドメイン取得済み(CognitoドメインACM証明書を作成するときに使います)
  • セキュリティグループは事前に適切に開放されているものを付与しているものとします。

 参考URL

 注意事項

  • ドメイン取得時に若干ハマったことがあったのでご紹介しておきます。

ドメインお名前.comで取得しました。1年間無料で更新費用さえ払わなければ更新するまで無料で使えます。
nozaki.comはさすがに取得済みであったため、nozaki2.comを取得しました。
ところが、ACM証明書のリクエストでステータスがいつまでも「保留中の検証」のまま・・

どうやらACM指定のDNS検証のためのCNAMEレコードがちゃんと登録されていないようで、試しにa.nozaki2.comで値をbにしたCNAMEレコードを登録してみても、問い合わせに返答がない。

$ dig a.nozaki2.com CNAME

; <<>> DiG 9.10.6 <<>> a.nozaki2.com CNAME
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40113
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;a.nozaki2.com.         IN  CNAME

それもそのはず。お名前.comで取得したドメインのレコードをRoute 53で登録しようと思ったら、お名前.com側でネームサーバーの変更を行い、Route 53のNSレコードを指定する必要があった。

この設定変更後、しばらくすると無事CNAMEが引けるようになった。

$ dig a.nozaki2.com CNAME

; <<>> DiG 9.10.6 <<>> a.nozaki2.com CNAME
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32984
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;a.nozaki2.com.         IN  CNAME

;; ANSWER SECTION:
a.nozaki2.com.      300 IN  CNAME   b.

証明書も無事「発行済み」に

  • Cognito設定後、永遠とredirect_mismatchエラーに見舞われることに

このサイトが参考になりました。どうやらコールバックURLが適切でないとこれが出る模様

「redirect_mismatch」エラーは、認証リクエストの redirect_uri パラメータが、Amazon Cognito でアプリに設定されたリダイレクト URI と一致しない場合に発生します。これは、ユーザーをブラウザから Android アプリにリダイレクトしようとしているときに発生する可能性があります。
Amazon Cognito でアプリを設定するときは、そのアプリのリダイレクト URI を指定する必要があります。リダイレクト URI は、ユーザーがサインインした後にリダイレクトされる URL です。認証リクエストのリダイレクト URI がアプリに設定されたリダイレクト URI と一致しない場合、Amazon Cognito は「redirect_mismatch」エラーを返します。

自分の場合はそれだけでは直らなかったため、アプリケーションクライアントの[ホストされた UI]を編集しました。

[OAuth 2.0 許可タイプ]で、「暗黙的な付与」も許可したら直りました。

 作業の流れ

 概要図

 事前作業

1.ターゲットグループの作成
HTTPS化。ヘルスチェックもHTTPS

2.ALBの作成
ネットワークマッピングでサブネットの指定がポイント。最初誤ってターゲットが存在するプライベートサブネットを指定してしまった。そうすると「インターネットゲートウェイへのルートがありません。」と警告が出るはず。インターネットfacingのALBの場合はそうするとインターネットから繋がらなくなってしまう。
なのでここはIGWが存在するパブリックサブネットを指定(もう一つのダミーのパブリックサブネットはIGWを置いていないので、このように警告出てます)

3.リスナーの指定
ALB⇨EC2でHTTPS化されたWebサイトを見に行けるようにしておく必要があるため、リスナーの作成がポイントになる。
プロトコルHTTPS化。そうするとセキュリティポリシー(デフォルトでOK)やACM証明書を指定する欄が現れる。


ACM証明書はこの場で作成してもOK。ここでは「注意事項」で苦労して作成したACMを指定

4.ALBのDNS名をRoute 53に追加
HTTPSアクセス自体はこれなしでもできますが、おそらく証明書の警告や覚えやすいドメインでアクセスしたい場合は必要な作業。ALBのDNS名は長くて覚えられないので
これにはAレコードのエイリアスレコードを使います。レコードの作成でAレコードのまま、「エイリアス」を有効化します。すると[トラフィックのルーティング先]という欄が現れるので、ALBやリージョン、dualstack〜と名付けられたALB名をそれぞれ選択します。



こうすることで、「test.nozaki2.com」でALB DNSにアクセスできるようになります。

まずはこれだけで無事Webページ(Testと表示)にアクセスできることを確認

 検証作業

次にいよいよCognitoを挟んでCognito認証+MFA化を行います。これが大変

  • Cogintoユーザープールの作成

1.サインインエクスペリエンスの認証プロバイダー

2.セキュリティ要件はデフォルトのままでOK。MFAを必須にします。
3.サインアップエクスペリエンスもデフォルトのままでOK
4.メールは[Cognito で E メールを送信]します。

5.アプリケーションを統合が一番大事です。
[Cognito のホストされた UI を使用]し、Cognitoドメインに取得しておいた「nozaki2.com」の「nozaki2」の部分だけを入れます。

クライアントシークレットを生成し、コールバックURLにnozaki2.comを入れます。ここはアクセスするときのURLと同じドメインを使用する必要があります。

これでCogintoユーザープールの作成が完了し、Cognito側の設定はおしまいです。

  • ALB側でCognitoを組み込む

ALBのHTTPS:443のリスナールールを編集して、Cognito認証の設定を加えます。ただ設定箇所が非常に場所が分かりづらいので注意
1.ALBを選択して、[リスナーとルール]タブを開き、[ルール]列にある「1個のルール」をクリック

2.するとブラウザの別タブでルールの詳細画面が開くので、この「デフォルト」ルールを選択した状態で、右上の[アクション]から「ルールの編集」をクリック

3.するとようやくリスナーの詳細を編集できる画面に飛ぶので、[OpenID または Amazon Cognito を使用する]をチェックして、各種設定項目に適切なものを選択

これでようやく当初の目的であるCognito(MFA)⇨ALB⇨EC2(Webサイト)の検証ができます。
「事前作業」のときと同じようにまずは「「https://test.nozaki2.com」にアクセス
するとこのようにCognitoの認証画面になります。

適切に認証すると、今度はMFAでパスコードを求められます。

手元のスマホでProtect Authenticatorを起動し、あらかじめ登録してあるアカウントに表示されているパスコードを入力すると、無事Webページが表示されました。

 所要時間

2時間

Transfer Family(FTP/FTPS)の作成とファイル転送の検証

サービス概要

Transfer Familyは、SFTP、FTPS、FTP、AS2 プロトコルを使用して、AWS Storage サービスへの定期的なファイル転送を安全に行うファイル転送サービスです。

 目的・やりたいこと

お客さんからTransfer Familyを使ってS3へのアップロード/ダウンロードしたい要望があったが、SFTPはともかく、はたしてFTP/FTPSに対しても無事意図通りのファイルのやり取りができるかどうか検証する。

 対象者

  • SFTP/FTPによってファイルをS3にアップロードしたい運用管理者

 対象となる技術

  • Transfer Family
  • FTP/FTPS
  • S3

 条件

  • Transfer Familyのサーバは作成済みとします
  • ファイル転送対象プロトコルは、今回はFTP/FTPSとします

  • FTPサーバ側のセキュリティグループには、あらかじめカスタムTCPポート21、8192〜8200を許可してあります

  • 管理用EC2を使いたくない場合はADはManaged AD以外のAD(EC2)にしましょう。Transfer FamilyではADグループにS3フルアクセスを許可したTransfer用ロールを付与する必要があるのですが、ブラックボックスなManaged ADにしてしまうとグループ名がわからないため
  • Managed ADでもこちらの方法こちらの方法で管理用EC2を使うことで管理できます。

 参考URL

 注意事項

  • エンドポイントの選択時に、[パブリックアクセス可能]にしようとすると「パブリックエンドポイントタイプを使用するには、ステップ 1 で AS2、FTPS、および FTP を無効にします」と言われてしまい次に進めないため、FTP/FTPSを選択した場合は自動的に[VPCでホスト]しか選択肢がないことに注意

     

  • 仮に[VPCでホスト]にしても、アクセスに[インターネット向け]を選ぶと「サーバーのエンドポイントは、VPC 内でのみホストできます (内部アクセスの場合のみ)。インターネット向け VPC エンドポイントタイプを使用するには、ステップ 1 で FTP を無効にします。」と言われてしまい次に進めないため、FTPを選択した場合は自動的に[内部]しか選択肢がないことに注意

     

つまり、FTPで直接外部から(インターネット経由で)エンドポイントを叩けないようになっているというワケ。まあそりゃそうか

 前提条件(制約事項)

クライアントを使用してサーバーエンドポイント経由でファイルを転送する

  • FTPSについては、明示モードのみがサポートされます。暗黙モードはサポートされません。
  • FTP および FTPS では、パッシブモードのみがサポートされます。
  • FTP および FTPS では、STREAM モードのみがサポートされます。
  • FTP および FTPS では、イメージ/バイナリモードのみがサポートされます。
  • FTP および FTPS の場合、データ接続の TLS-PROT C (非保護) TLS がデフォルトですが、PROT C は AWS Transfer Family プロトコルでサポートされません。そのため、FTPSの場合、データ操作を受け付けるにはPROT Pを発行する必要があります。
  • サーバーのストレージに S3 を使用していて、クライアントに 1 回の転送で複数の接続を使用するオプションがある場合は、そのオプションを必ず無効にしてください。なお、ストレージのバックエンドにEFSを使用している場合、EFSは1回の転送に複数の接続をサポートしています。

ちなみに、現在FTPではクライアント側からデータ転送用のコネクションを繋ぐパッシブモードが主流です。

 

 作業の流れ

 概要図

 

 事前作業

  • Transfer Familyのサーバは作成してオンライン済みとします。 

1. Powershell を開いて次のコマンドを実行して、admin2グループの SID を確認

> Get-ADGroup -Filter {samAccountName -like "admin2*"} -Properties * | Select SamAccountName,ObjectSid

SamAccountName ObjectSid
-------------- ---------
admin2         S-1-5-21-1393767525-1197825293-1881432246-1112

2.Transfer用にS2FullAccessを付与したロールを作成

2.作成したFTPサーバーでは以下の表示が出るはずなので、[アクセスの追加]

3.1.のSIDと、2.のロールを付与して[追加]

4.テスト、以下のような応答が返れば成功

5.VPCエンドポイントが作成されていることを確認


この「vpce-0a931405e5c6f5afb-p4v2rhey.vpce-svc-0cee93c75e789f90b.ap-northeast-1.vpce.amazonaws.com」というDNSでアクセスします。ちなみにこのDNS名はプライベートアドレスに名前解決されます。

 検証手順

ここではLinuxアクセスによるFTPアップロード検証は割愛し、WindowsからWinSCPを使用してS3にアクセスする前提とします。

1.Transfer Family(FTP)は直接アクセスできないため、まずは同一サブネットにある踏み台Windowsにログオン

2.WinSCPを立ち上げ、以下のように入力


ホスト名:VPCエンドポイントのDNS
(ちなみにVPCエンドポイントは2つに冗長化されているのだが、DNS名が3つもあるのはなぜだろう?)
ユーザー名:ADユーザー名
パスワード:ADパスワード
暗号化:暗号化なしのFTPとします

3.すると次のようにS3バケットにつながり、無事成功。ファイルのやり取りもできました。

4.ちなみにここでもしパッシブモードをオフにしたらどうなるでしょう?

5.リモートディレクトリの読み込み中にリスト取得エラーとなりました。ここはやはり仕様のとおり

6.では[暗黙のTTL/SSL暗号化]を選んだら?

7.接続中のまま進まなくなり、やがてタイムアウトしました。これも仕様通り

8.では逆に[明示的なTLS/SSL暗号化]すなわちFTPSにしてみると?


これもすんなり接続できました。でも自己署名証明書などを使っていると警告が出ることもあるみたい

 所要時間

1時間

 追加検証(FTPの代わりにFTPSを使うなら?)

注意事項で、[VPCでホスト][インターネット向け]を選ぶにはFTPを無効にするしかないと述べましたが、ではFTPを無効にしてFTPSにすれば[インターネット向け]にできるのでは?ということでやってみます。


冗長化構成にするとなんとEIPを2つも使ってしまうというじゃぶじゃぶな贅沢な使い方になります。

それでいて、カスタムホスト名のところを[その他のDNS]ではなく、[Route 53 DNSエイリアス]にすると、


作成時にホスト名にリンクが貼られ、


そのリンク先に飛ぶと、このようなTransfer Familyのエンドポイントを値としたCNAMEレコードが自動生成されてます!

 

さていよいよ自PCのMacで外部からこのFTPSサーバーに着信させるわけですが、その前に一つ大事なポイントがあります。
初外部着信のため、21番のセキュリティグループを外部に公開(許可)する!
これを忘れていたがゆえにしばらくハマってしまったため、忘れないようにしましょう。

また、それでもログインまでいくものの、どうしてもディレクトリリストの取得中...で止まってしまっていた。セキュリティグループを全開放するとこれが進展することから、Mac側にWireSharkを入れてどんなポートでFTPサーバーとやりとりしているか見てみました。すると21番はもちろん、8192〜8199番くらいのランダムなポートでサーバに繋ぎに行ってることに気付きました。
それもそのはず、こちらの仕様にちゃんと注記されてるじゃないですか!

トランスファーファミリーのFTPサーバーは、ポート21(コントロールチャネル)とポート範囲8192~8200(データチャネル)で動作します。

この状態でいよいよMacFileZillaにてログイン試行!


(ポートは毎回21とか指定しなくても勝手に21番ポートで接続しに行ってるようです)
するとこのようなメッセージが表示され、右側にS3バケット一覧が見れれば成功です!

というわけで、FTPSにした場合はTransfer Familyエンドポイントをインターネット向けとして設置でき、外部から直接接続できるというわけです。