Identity Aware Proxy (IAP) を使用してアクセスを一元管理する。

## はじめに

この記事は、
　[Centralize access to your organization’s websites with Identity Aware Proxy (IAP)](https://www.youtube.com/watch?v=xM9-FSU5MoY)
という動画を参考に、『実際にやってみた』という記事になります。


## この記事でできるようになる事
`Identity Aware Proxy　(IAP)`で、
アクセスの一元管理を行えるようにする。

以下はその必要となる大まかな構成になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/d10aaded-723e-6c52-a99b-c4532948ac52.png)


## 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`を使用した一元管理の確認が目的ですので、
以下のクイックスタートを利用しまして、それぞれ環境をデプロイします。

https://cloud.google.com/appengine/docs/legacy/standard/go111/create-app?hl=ja

環境は、３つ用意します。
それぞれデプロイ後にアクセスすると、以下のメッセージが表示されるようにします。

- 一般公開用
![appengine_public.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/3ad1e5a1-9b05-12ce-d6fe-5e0f659f74dd.png)

- 会員専用
![appengine_members.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/c17124aa-ca74-5565-6234-56b33d8111a7.png)

- 従業員専用
![appengine_employees.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/6df828a9-dc31-78f1-b44c-6869e957f198.png)

また、デプロイする際は、service名や
表示するメッセージは環境ごとに変えてください。

この対応は、それぞれ`IAP`を使用してアクセスが
一元管理できているか確認する為です。

`app.yaml`
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/d4107f44-2397-8f7e-8d4f-946b2affc2ce.png)
`helloworld.go`
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/84c79841-d7e3-83c2-c923-e0e920c19c72.png)


## `IAP` を利用するための準備を行う。
今回は、App Engine を利用しているため、
以下の ガイドを利用して、`IAP`の設定を進めていきます。

https://cloud.google.com/iap/docs/enabling-app-engine?hl=ja

`IAP` で保護するプロジェクトを選択して、 『`APIを有効にする`』を選択してください。
※`Identity-Aware Proxy API` はこのステップでも有効にすることができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/0092fb63-22f8-dfed-700d-0b35dfa1c9cd.png)

APIを有効にすると、`OAuth同意画面`の構成を設定するように
メッセージが表示されますので、その指示に従って設定を行なってください。

ただし、一度設定してしまうと、サポートに問い合わせるか、
プロジェクトそのものを消さない限り消せなくなっている為、
操作は慎重に行うようにしてください。

アクセスの一元管理を別の方法や手段で試す事があれば、
一度、ここで手を止めるもありだと思います。

今回は、`IAP`を使用して、アクセスを一元管理する事が
目的なので、このまま作業を進めます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/a7b6a9f1-bdc0-3b14-7640-58a4afd89b91.png)

なお、この記事では、OAuth同意画面での説明は
省きますので、画面の指示に従って作成を進めてください。

`OAuth`を設定後、再度`Identity-Aware Proxy`を
開いて、`IAP`の有効化を実行すれば、`IAP`を利用する準備は完了です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/4a66c5f0-7d35-2e3b-13a0-08aaff3d356c.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/0d0b0968-c6b8-8347-7fa8-e6cb1070787f.png)


## `IAP`が機能しているか検証する。
この時点では、`IAP`を有効にしただけで、何も設定していませんが、
`IAP`が機能しているか試しておきたいと思います。

`IAP`でアクセスを一元管理したいサービスを
どれでも良いので、アクセスしてみて、
以下のメッセージが表示されていれば、
`IAP`が機能している事を証明できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/0c992d4f-6e10-5a31-839d-a3d5be35db34.png)


## 一般公開用のIAPを設定する。
ここでは、一般公開用に準備したアプリケーションに対して、
以下の設定を行うことで、`IAP`を経由する
パブリックアクセスを可能とする設定を行います。

新しいプリンシパル：`allUsers`
ロール：`IAP-secured Web App User`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/18fb1899-8b4b-3d88-cf41-7286c2839fdc.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/6713bfa8-268d-8c9d-23b3-46caaa1e1733.png)

再度、一般公開用のアプリケーションに対して、
ユーザー認証が表示されず、アプリケーションへ
正常にアクセスできれば、一般公開用の設定は完了になります。

![appengine_public.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/3ad1e5a1-9b05-12ce-d6fe-5e0f659f74dd.png)


## ユーザー認証を必要とするIAPを設定する。
ここでは、ユーザー認証を必要とするアプリケーションには、
以下の設定を行うことで、ユーザー認証を経由して、
アプリケーションへアクセスできるようにします。

新しいプリンシパル：`allAuthenticatedUsers`
ロール：`IAP-secured Web App User`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/9886e67a-2272-d9d9-aeda-f025e3a04f00.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/6713bfa8-268d-8c9d-23b3-46caaa1e1733.png)

再度、ユーザー認証用のアプリケーションに対して、
ユーザー認証を経由し、アプリケーションへ
正常にアクセスできれば、ユーザー認証が
必要となるIAPの設定は完了になります。

![appengine_members.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/c17124aa-ca74-5565-6234-56b33d8111a7.png)


## 特定のユーザーのみアクセスを許可するIAPを設定する。
ここでは、ユーザー認証後、さらにそのユーザーが
アクセスしても良いかをIAPが判断してから、
アプリケーションへアクセスできるようにします。

新しいプリンシパル：`アプリケーションへアクセスを許可するメールアドレス`
ロール：`IAP-secured Web App User`

![IAP_config_02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/10522b7e-89c8-0e41-7b82-870a1531b57a.png)

再度、ユーザー認証用のアプリケーションに対して、
ユーザー認証を経由し、許可されたアドレスのみ
アクセスができれば設定は完了になります。

アクセスを許可していないユーザーで認証を行うと以下の画面が表示されます。
![IAP_config_03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/231de367-d7ce-93d2-62a4-140900750a91.png)

アクセスを許可されたユーザーで認証を行うと以下の画面が表示されます。
![IAP_config_04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/b19185ac-fd5c-c1d1-02fc-03355861f9c8.png)

このようにアクセスを許可されたユーザーは認証後、
そのユーザーIDがヘッダー情報として、Webサーバーや
アプリケーション側に渡ることで、許可されたユーザーであることを
確認できれば、アクセスすることが可能となります。

## 終わりに
今回の記事は、動画を視聴しまして、
実際に『手を動かしてみた』という内容でまとめました。

`Identity Aware Proxy` を設定しておくことで、
悪意のあるユーザーからのアクセスからサービスや
アプリケーションを守れる手段の一つを学べました。

セキュリティの手段や方法は多種多様ありますが、
IAPの設定はシンプルに、不特定の悪意のあるユーザーを
対象とするのではなく、アクセスしても問題ない、
自分自身が知っている特定ユーザーのみを
対象に許可できるといった処も、使い勝手良いと思いました。

`Identity Aware Proxy`がどのようなものか、
試してみたい人は、参考にしていただけると幸いです。

なお、今回の記事では、`IAP-secured Web App User` ロールを、
`allUsers` プリンシパルと `allAuthenticatedUsers` プリンシパルに
付与していますが、通常のベストプラクティスと異なり、
これらのプリンシパルに対して、付与されることは、推奨されていません。

あとで『じっくり読みたい』、『繰り返し読みたい』と
思ってくれましたら、『`ストック`』へ登録、
この記事が読まれている方にとって、
参考になる記事となりましたら、『`いいね`』を
付けていただけますと、励みになりますので、
よろしくお願いします。