内部向けWebシステムでのALB認証による外部からの利用の検証

こんにちは、技術4課の城です。
今回は既存Webシステムへの外部からのアクセスに対する認証として、ALBの認証機能を利用する検証をしてみました。
通常は社内ネットワークからDirectConnectやVPN回線経由で利用しているシステムに対して、インターネット経由の窓口としてのALBを追加するような用途を想定しています。

要件

要件としては下記となります。

• 既存社内Webシステムに対して、外部からアクセスさせる。
• 既存Webシステムの変更は行わない。
• Webシステムにアクセスさせる前段で多要素認証を実施。（ログイン画面へのアタック防止）

概要

検証してみた結果、下記の構成は実現することが出来ました。

• ホストベースのルーティングにて複数システムを1つのALBに紐づけ
• CognitoユーザープールでのSMSによる多要素認証

構成図は下図となります。

利用したサービス一覧

利用したサービスとおおまかな内容は下記となります。

• Route53
• • ALBへのエイリアスレコードの登録
  • ワイルドカード証明書作成のための検証
• ACM
• • ワイルドカード証明書作成
• ALB
• • HTTPSリスナー
  • ホスト名ベースのルーティング
  • 認証
  • ターゲットグループは各システム用に２つ作成
• Cognitoユーザープール
• • ユーザープールは各システム用に２つ作成
  • 多要素認証はSMSを利用
• EC2
• • 仮想社内システム用

Cognitoユーザープールの作成

それぞれのシステム用に2つのユーザープールを作成します。

プール名の指定

属性の指定

今回はEメールアドレスをユーザー名としました。
SMSでの多要素認証を利用するため、phone numberも必須としています。

ポリシーの指定

パスワード強度、有効期限はデフォルトのまま、管理者のみユーザの作成を許可としています。

MFAの設定

今回はMFA必須、SMSテキストメッセージでの認証としています。
Eメール、電話番号の検証を必須とし、[ロールの作成]ボタンをクリックしてSMS送信に必要なIAMロールを作成します。

後で調べたところ、下記のポリシーが付与されたロールが作成されていました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sns:publish"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Amazon SNSのサービス上限

ここでちょっと気になるメッセージが出ていました。

重要：ユーザーに SMSメッセージを送信して電話番号の確認やMFAを行うには、Amazon SNSに対して使用量の上限の引き上げをリクエストする必要があります。

Amazon SNSのデフォルトのSMSメッセージ使用量上限は1$となっており、十数通メッセージを送ると上限に達してしまいます。
SMSメッセージの料金表は下記です。
https://aws.amazon.com/jp/sns/sms-pricing/

AWSサポートへの上限緩和申請とSNSのアカウントの使用制限の設定を忘れずに行っておきましょう。

私はこのblogの検証環境を得意気に上司に見せている時に上限にかかり、ワンタイムパスワードが送信されず、半泣きになってました。
SMS14通目でした。絶対に忘れません。

メッセージのカスタマイズ

デフォルトのままとしました。

タグ

タグはなしで[次のステップ]にいきます。

デバイスの記憶

デバイスの記憶はなしで[次のステップ]にいきます。

デバイスの記憶について詳細は下記をご参照ください。
https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/amazon-cognito-user-pools-device-tracking.html

アプリクライアントの設定

[アプリクライアントの追加]をクリックします。

デフォルト設定のまま、アプリクライアント名を入力し、[次のステップ]をクリックします。

[次のステップ]をクリックします。

トリガー

こちらもデフォルトのまま[次のステップ]をクリックします。

確認と作成

設定値を確認し[プールの作成]をクリックします。

作成できました。

アプリクライアントの設定追加

下記ドキュメントを参考にして、設定を行いました。
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/listener-authenticate-users.html
実際にした設定としては下記となります。

ドメイン名の指定

ここではAmazon Cognitoのサインインページで利用されるドメインを指定します。
今回はホストされたドメインを利用しました。

ユーザーの作成

ユーザープールの管理画面の[ユーザーとグループ]にて[ユーザーの作成]をクリックします。

必要な情報を入力します。
注意点ですが、電話番号は国番号を含めた形で記載する必要があります。
【誤】

【正】

ユーザーを作成できました。

Cognitoの設定は以上です。

ワイルドカード証明書の作成

ALB認証はHTTPSリスナーのみ利用できますので、今回はACMにてワイルドカード証明書を作成しておきます。
作成手順についてはこちらをご覧ください。

ターゲットグループの作成

こちらもそれぞれのホスト用に2つのターゲットグループ、ブラックホール用のターゲットグループを１つ作成します。
ホスト用には仮想社内システムとして作成した、２台のEC2をそれぞれ登録しました。
ブラックホール用にはインスタンスの登録されていないターゲットグループを作成します。
これはデフォルトのルールに適用し、レスポンスを返さないようにするためです。
デフォルトのルールに該当するアクセスは、具体的にはALBのエンドポイントに直接アクセスをされるケースを想定しています。

ALBの作成

ALBを作成します。
詳細な作成方法については省略します。
ポチポチっと作成しましょう。

リスナーのルールの設定

下記のように設定しています。

Route53の設定

構成図にも記載のとおり、下記サブドメインのエイリアスレコードに作成したALBを登録しました。
ap01.testdomain-jo.tk
ap02.testdomain-jo.tk

アクセス確認

アクセスしてみます。
【ID・パスワード認証画面】

【ワンタイムパスワード認証画面】
登録した電話番号にSMSでワンタイムパスワードが送られてくるので入力します。

ap01にアクセスできました！

ap02も同様に認証後、アクセスできました。

最後に

全くなれない認証の分野ではあったのですが、ある程度容易に多要素認証を追加することが出来ました。
個人的にはCognito、OAuth2.0の仕様などについて、もう少し深く理解していきたいところです。