Amazon WorkLinkを試してみた（IdPとしてAWS SSOを利用する場合）
はじめに
中山です
WorkLinkってサービスをご存じでしょうか？
今年の1月にリリースされたサービスなのですが、まだ東京では提供されていないためか、日本語での技術情報が公式のドキュメント以外ではほぼありませんでした（ニュースサイトの紹介記事を除く）。 唯一見つけた情報はこちらです。さすがクラウドネイティブさん。
WorkLinkとは？
クローズドなネットワーク内にあるWebサービスへモバイルデバイス (Android, iOS) でセキュアにアクセスための手段を提供します。
ユーザー認証はSAMLに対応したIdPと連携することができ、特定の要件を満たしたデバイスのみにアクセスを許可するような制御も可能です。 デバイス - WorkLink 間の通信はVPNで暗号化されます。
。。。と書いたものの、ちゃんとさわってないので正直仕組みがよくわかりません。 そういうときはやってみるに限りますのでやってみます。
やってみた
今回はIdPとしてAWS SSOを利用します。一番簡単そうだったので。
基本的には以下のドキュメントの記載に沿って進めていきます。
Getting Started with Amazon WorkLink
前提条件
予め以下の設定ができていることを前提に説明を進めます。
- AWS SSOの有効化
- ユーザーはAWS SSO内で管理（Directory Serviceは利用しない）
- AWS SSO上でユーザーを定義済み
- アプリケーションとの連携設定とユーザーの割り当ては後述
- バージニアリージョンを利用
- クローズドなサイトとそれを配置するVPC
- 今回はWordPressを構築しておく（bitnamiのAMIを使用）
- オレゴンリージョンを利用
- 組織で利用するドメインのゾーンをRoute53で作成済み
以下の図のような構成がすでにできているという前提で構築手順を紹介します。
最終的にはこうなります。
それでは、はじめていきます。
フリートの作成
まず、WorkLinkのフリートを作成します。
フリートの名前を指定します。
まずはフリートができました。 しかし、これだけでは利用できないので各種設定を進めていきます。 フリート名の部分がリンクになっているので、クリックします。
IdPとの連携
まずは、IdPとの連携を行います。
まずは、IdPのメタデータファイルをIdP側からダウンロードしてここからアップロードします。
ここで、WorkLinkの画面を一度離れて、AWS SSOの設定画面に移動します。
WorkLinkを連携するアプリケーション (SP = Service Provider) として登録します。
WorkLinkを選択します。
すると、SAML Metadata Fileをダウンロードできるので、これをダウンロードします。
ダウンロードしたSAML Metadata FileをWorkLinkの設定画面からアップロードします。
Linkを完了し、今度はSPのMetadata Fileをダウンロードし、IdPにアップロードします。
アップロードし、設定を保存します。
一旦設定ができましたが、これでは不十分だったので追加で設定を行います。
まず、マッピングする属性のフォーマットを"emailaddress"に変更します。
次に、AWS SSO内のユーザーをアプリケーションに割り当てます。
WorkLinkを利用させるユーザを選択します。
これでAWS SSO側の設定は完了です。 WorkLinkの画面に戻ります。
ドメインの関連付け
ドメインの関連付けを行います。
ここでは、プラーベートネットワーク内のリソースにアクセスするためのFQDNを設定します。 また、そのドメインの所有権を検証するためにACMでそのドメインの証明書を作成／選択する必要があります。 この証明書はバージニアリージョンで作成する必要があります。
Prepare TLS Certificates for Company Domains in AWS Certificate Manager
ドメインの関連付けは以上です。
VPCの関連付け
WorkLinkのFleetとVPCを関連付けます。
VPC, Subnet, Security Groupを指定します。
完了です。
ちなみに、このSecurity GroupはWorkLinkのために生成されるENIに割り当てるSecurity Groupです。
ALBの作成 / Aliasレコードの作成
WorkLinkとしての設定はここまでなのですが、ドメインの関連付けで指定したホスト名でローカルIPアドレスを指定するように構成してみました。 しかし、これでは正常にアクセスすることができませんでした。
そこで、以下の作業を追加で実施しました。
- ALB(Internal)を作成し、EC2インスタンスをターゲットに設定
- ListenerはHTTPSで作成し、TLSをTerminate
- ACMで証明書を作成
- ALBのEndpointをALIASレコードとして登録
動作確認
動作確認してみます。 利用するには、専用のアプリとカンパニーコードが必要です。
今回はAndroidでやってみます
起動するとこんな感じです。
カンパニーコードを入力します。
AWS SSOのユーザーで認証します。
これで接続完了です。
Chromeを開き、ドメインの関連付けで設定したFQDNでアクセスします。 WordPressの画面が開きました。 表示が崩れているのはご愛嬌・・・
AWSのコンソールでユーザーとデバイスの情報も確認しておきましょう。
まず、ログインしているユーザを確認できます。
また、接続したデバイスの情報も確認できます。
Patch Levelも確認できるの良いですね。
まとめ
WorkLinkがハマるユースケースがどんなものか、まだイメージできていませんが、WorkSpaces / AppStream 2.0 / Client VPN に加えてAWS上のプライベートなリソースへのアクセス方法が増えました。
ターゲットがWebサービスであれば、他のサービスより安価にアクセスすることが可能となります。 東京リージョンでのサービス提供はまだですが、リモートから社内のリソース（Webサービス）へアクセスさせたい場合にはよい選択肢なのではないでしょうか？
現場からは以上です。
次にやりたいこと
需要があれば、以下のこともやってみたいなーと思います。
- デバイスポリシーによるアクセス制御
- 他のIdPとの連携（Auth0やOneLoginなど）
