はじめに
この記事は、
Centralize access to your organization’s websites with Identity Aware Proxy (IAP)
という動画を参考に、『実際にやってみた』という記事になります。
この記事でできるようになる事
Identity Aware Proxy (IAP)で、
アクセスの一元管理を行えるようにする。
以下はその必要となる大まかな構成になります。
Identity Aware Proxy (IAP) について理解しておく
Identity Aware Proxy (IAP) は、Google Cloudのセキュリティサービスの一環で、
アプリケーションへのアクセスを管理し、強化するための重要なツールです。
IAPを使用することで、ユーザーがアプリケーションにアクセスする際、
そのユーザーのアイデンティティとアクセス許可を確認することができます。
これにより、認証されていないユーザーや
不正なアクセスからアプリケーションを保護することが可能。
IAPは、Google Cloudの多くのサービスとシームレスに統合でき、
HTTPリクエストを介してアプリケーションにアクセスする
ユーザーのアイデンティティ情報を取得し、アクセス許可をチェック、
これにより、アプリケーションへのアクセスを制御し、
セキュリティを向上することができる。
さらに、IAPは多要素認証（MFA）などのセキュリティ機能も提供し、
アクセスをより堅牢に保護することもできる。
また、アクセスの監視やログの収集を支援し、
セキュリティインシデントの追跡と対応も容易となる。
IAPは、Google Cloudのセキュリティ要件を満たすために
幅広く活用されており、アプリケーションやリソースへの
セキュアなアクセスを確保するための不可欠なツールとなっています。
なお、IAPは、Googleアカウントを持たないユーザーや、
Googleアカウントを使用しないアプリケーションに
対しても利用できるセキュリティサービスです。
ユーザーがGoogleアカウントを持っていない場合でも、
IAPは他の認証プロバイダーやメカニズムを使用して
ユーザーを認証することが可能です。
そのため、IAPはGoogleアカウントに依存しない
柔軟な認証オプションを提供していると言えます。
Google Cloud API を有効化
GCPプロジェクトのコンソールへ接続。
Identity-Aware Proxy API
Artifact Registry API
これらのAPIを有効化。
その他、APIの有効化は、必要に応じて、適宜行ってください。
アプリケーションファイルを準備してデプロイする。
今回はIAPを使用した一元管理の確認が目的ですので、
以下のクイックスタートを利用しまして、それぞれ環境をデプロイします。
環境は、３つ用意します。
それぞれデプロイ後にアクセスすると、以下のメッセージが表示されるようにします。
-
一般公開用
-
会員専用
-
従業員専用
また、デプロイする際は、service名や
表示するメッセージは環境ごとに変えてください。
この対応は、それぞれIAPを使用してアクセスが
一元管理できているか確認する為です。
app.yaml
helloworld.go
IAP を利用するための準備を行う。
今回は、App Engine を利用しているため、
以下の ガイドを利用して、IAPの設定を進めていきます。
IAP で保護するプロジェクトを選択して、 『APIを有効にする』を選択してください。
※Identity-Aware Proxy API はこのステップでも有効にすることができます。
APIを有効にすると、OAuth同意画面の構成を設定するように
メッセージが表示されますので、その指示に従って設定を行なってください。
ただし、一度設定してしまうと、サポートに問い合わせるか、
プロジェクトそのものを消さない限り消せなくなっている為、
操作は慎重に行うようにしてください。
アクセスの一元管理を別の方法や手段で試す事があれば、
一度、ここで手を止めるもありだと思います。
今回は、IAPを使用して、アクセスを一元管理する事が
目的なので、このまま作業を進めます。
なお、この記事では、OAuth同意画面での説明は
省きますので、画面の指示に従って作成を進めてください。
OAuthを設定後、再度Identity-Aware Proxyを
開いて、IAPの有効化を実行すれば、IAPを利用する準備は完了です。
IAPが機能しているか検証する。
この時点では、IAPを有効にしただけで、何も設定していませんが、
IAPが機能しているか試しておきたいと思います。
IAPでアクセスを一元管理したいサービスを
どれでも良いので、アクセスしてみて、
以下のメッセージが表示されていれば、
IAPが機能している事を証明できます。
一般公開用のIAPを設定する。
ここでは、一般公開用に準備したアプリケーションに対して、
以下の設定を行うことで、IAPを経由する
パブリックアクセスを可能とする設定を行います。
新しいプリンシパル：allUsers
ロール：IAP-secured Web App User
再度、一般公開用のアプリケーションに対して、
ユーザー認証が表示されず、アプリケーションへ
正常にアクセスできれば、一般公開用の設定は完了になります。
ユーザー認証を必要とするIAPを設定する。
ここでは、ユーザー認証を必要とするアプリケーションには、
以下の設定を行うことで、ユーザー認証を経由して、
アプリケーションへアクセスできるようにします。
新しいプリンシパル：allAuthenticatedUsers
ロール：IAP-secured Web App User
再度、ユーザー認証用のアプリケーションに対して、
ユーザー認証を経由し、アプリケーションへ
正常にアクセスできれば、ユーザー認証が
必要となるIAPの設定は完了になります。
特定のユーザーのみアクセスを許可するIAPを設定する。
ここでは、ユーザー認証後、さらにそのユーザーが
アクセスしても良いかをIAPが判断してから、
アプリケーションへアクセスできるようにします。
新しいプリンシパル：アプリケーションへアクセスを許可するメールアドレス
ロール：IAP-secured Web App User
再度、ユーザー認証用のアプリケーションに対して、
ユーザー認証を経由し、許可されたアドレスのみ
アクセスができれば設定は完了になります。
アクセスを許可していないユーザーで認証を行うと以下の画面が表示されます。
アクセスを許可されたユーザーで認証を行うと以下の画面が表示されます。
このようにアクセスを許可されたユーザーは認証後、
そのユーザーIDがヘッダー情報として、Webサーバーや
アプリケーション側に渡ることで、許可されたユーザーであることを
確認できれば、アクセスすることが可能となります。
終わりに
今回の記事は、動画を視聴しまして、
実際に『手を動かしてみた』という内容でまとめました。
Identity Aware Proxy を設定しておくことで、
悪意のあるユーザーからのアクセスからサービスや
アプリケーションを守れる手段の一つを学べました。
セキュリティの手段や方法は多種多様ありますが、
IAPの設定はシンプルに、不特定の悪意のあるユーザーを
対象とするのではなく、アクセスしても問題ない、
自分自身が知っている特定ユーザーのみを
対象に許可できるといった処も、使い勝手良いと思いました。
Identity Aware Proxyがどのようなものか、
試してみたい人は、参考にしていただけると幸いです。
なお、今回の記事では、IAP-secured Web App User ロールを、
allUsers プリンシパルと allAuthenticatedUsers プリンシパルに
付与していますが、通常のベストプラクティスと異なり、
これらのプリンシパルに対して、付与されることは、推奨されていません。
あとで『じっくり読みたい』、『繰り返し読みたい』と
思ってくれましたら、『ストック』へ登録、
この記事が読まれている方にとって、
参考になる記事となりましたら、『いいね』を
付けていただけますと、励みになりますので、
よろしくお願いします。