導入
- 2023年10月9日から、AWS Verified Accessが東京リージョンで利用可能となりました！
- AWS Verfied Accessを利用すると、ゼロトラストの基本原則に基づき、プライベートアプリケーションへのVPNレスでのアクセスを実装することができます。
- 本記事では、
ゼロトラストの基本原則を簡単に説明した上で、公式チュートリアルを参考に、AWS Verified Accessを実際に構築してみます。
ゼロトラストの基本原則について
- AWS でのゼロトラストでは、AWSでゼロトラストを構築するための基本原則について、以下3点をあげています。
- 可能な場合は、ID 機能とネットワーク機能を併用します。→Verified Accessであれば、
IAM Identity CenterやOpenID Connectとの統合により、IDとネットワークの併用によるアクセス制御ができそうです。 - 特定のユースケースから逆算して作業する→Verified Accessは主に、組織内部アプリケーションへのアクセス制御用途で採用されると思いますが、ポリシーの例等を参考にした、組織のニーズ・ユースケースを踏まえたアクセスポリシー設計が肝になりそうです
- システムとデータの価値に応じてゼロトラストを適用します→ゼロトラストに限らず、セキュリティ対策の目的は
リスクを許容可能な程度にコントロールすることであり、費用対効果を無視した過剰なセキュリティ対策は避ける必要があります。
AWS Verified Accessの構築
IAM Identity Centerの有効化
-
ステップ 1: IAM ID センターを有効にするを参考に、
IAM Identity Centerを東京リージョンで有効化します。
内部アプリケーションの構築
- プライベートサブネット上にLambda関数を作成します。
def lambda_handler(event, context):
return {
'statusCode': 200,
'headers': {'Content-Type': 'text/html'},
'body': '<p>Access Allowed!!!</p>'
}
- 内部用ALB向けにオレオレ証明書を作成し、ACMにインポートします。
# 秘密鍵の作成
openssl genrsa 2048 > server.key
# CSRの作成
openssl req -new -key server.key > server.csr
# CSRの確認
openssl req -in server.csr -text
# オレオレ証明証の作成
openssl x509 -days 3650 -req -sha256 -signkey server.key < server.csr > server.crt
-
ALBのターゲットグループを作成し、先程作成したLambda関数をターゲットとして指定します。
-
プライベートサブネット上に内部用ALBを作成し、先程作成したターゲットグループを紐づけます。
-
内部用ALB向けに、Route53のプライベートホストゾーンにレコードを作成します。
- レコードタイプ： A
- エイリアス： 有効化
- トラフィックのルーティング： 先程作成したALBを指定
Verified Accessインスタンスと信頼プロバイダーを作成する
-
VPCコンソールにアクセスし、ナビゲーションペインから
Verified Access インスタンスを選択します。 -
Verified Accessインスタンスを作成を押下し、インスタンスを作成します。
-
インスタンス作成画面で
Verified Access 信頼プロバイダーを作成を押下して、別タブで信頼プロバイダーを作成します。
-
元のタブに戻り、先ほど作成した信頼プロバイダーをアタッチして、インスタンスを作成します。
Verified Accessグループを作成する
- ナビゲーションペインから
Verified Access グループを選択し、Verified Access グループを作成を押下します。 - 先程作成したインスタンスをアタッチします。
- ポリシーには無条件のアクセス許可を設定します。
permit(principal,action,resource) when {true};
Verified Accessエンドポイントを作成する
-
事前準備として、
- Verified Accessエンドポイント用SGを作成します。
- 自身のグローバルIPアドレスからのインバウンドHTTPS通信のみを許可するように設定しました。
- Verified Accessエンドポイント用パブリック証明書をACMで作成します。(自身が持つパブリックなカスタムドメインに対して、エンドポイント用サブドメインを切る必要があります）
- Verified Accessエンドポイント用SGを作成します。
-
ナビゲーションペインから
Verified Access エンドポイントを選択し、Verified Access エンドポイントを作成を押下します。- アプリケーションドメイン： 自身が持つカスタムドメインに対して、サブドメイン
hogeを切りました。 - ドメイン証明書のARN： 先程作成したACMのパブリック証明書を指定しました。
- アプリケーションドメイン： 自身が持つカスタムドメインに対して、サブドメイン
-
エンドポイントドメインをカスタムドメインのホストゾーンにCNAMEとして登録します。
動作確認
- Verified Access エンドポイントのアプリケーションドメインに対して、Webブラウザからアクセスします。
- サインインすると、無事Lambda関数が実行されました！
最後に
- 今回の記事では、AWS Verified Accessを実際に構築してみました。
- 次回以降の記事では、(ゼロトラストつながりで)
NIST SP800-207 ゼロトラスト・アーキテクチャの解説や、アクセスポリシーの設計についてDeepDiveできればと思います。
注意事項
- 本記事は万全を期して作成していますが、お気づきの点がありましたら、ご連絡よろしくお願いします。
- なお、本記事の内容を利用した結果及び影響について、筆者は一切の責任を負いませんので、予めご了承ください。