今日からやれる(ケースもある)BeyondCorp Remote Access

2020年4月21日(このpost書いた日)、こちらのニュースでリモートワークを導入する企業向けのソリューションであるBeyondCorp Remote Accessが紹介されました。
[Keep your teams working safely with BeyondCorp Remote Access | Google Cloud Blog](https://cloud.google.com/blog/products/identity-security/keep-your-teams-working-safely-with-beyondcorp-remote-access)

このpostでは、主に非GCP環境で社内NWに対して業務用のアプリケーションを配信している企業を想定してBeyondCorp Remote Accessを紹介していきます(GCP上でホストされたアプリケーションについてはやるだけ感が強いので)

# 時間がない人向け
## 誰がBeyondCorp Remote Accessを採用すべきか
かなりざっくりした軸としては「既に何らかのソリューションがあるかどうか」という点が最初にあると思います

- VPNも何もなく、社外からは業務用のWebアプリケーションにアクセスできなくてさて困ったぞ、という方は検討の価値あり
- うちはVPNあるけどセキュリティ的に不安だからどうしよう、という人はVPNをセキュアに使う方向で検討してみてから改めてこっちを考えてみたほうが良さそう
- うちはGCP上で社内向けアプリを配信しているぜ！という方は今日からでもやれます
    - *これ以外の人は今日からやるのはさすがに難しそうです*[^5]

[^5]: すみません


最初から全オープン、みたいな人はまあこれを機に検討してみると良いかと思います

## そもそもBeyondCorp Remote Accessを採用できない人
残念ながら、少なくとも今紹介されているhow toを参照する限り、採用できない人はいます(自分で1から仕組みを構築すれば同様の概念はできるとは思いますがまあそういうタフガイはこれ読んでなさそう)
下の方の `注意点` にも一部ありますが、こういう人たちにはnot for youな気がします

- アクセス対象がHTTPベースのアプリケーションでない人
- GSuiteで組織を管理していない人
- そもそも外部/Googleのネットワーク経由でのアクセスを許可していない人

# BeyondCorp Remote Accessは単体のプロダクトではない
GCPになにか新しいプロダクトが出たわけではなく、複数の製品を組合わせて外部から社内のプロダクトに対しての安全なアクセスを行うためのHowToみたいなものだと捉えています。
いくつかのプロダクトを利用して安全なリモートアクセスを実現していますが、その中でも特にコアになっているプロダクトは[Identity-Aware Proxy](https://cloud.google.com/iap/docs/concepts-overview?hl=ja)です。
このあたりについては後述します。

# 参照するドキュメント
以下のソリューションの概要ページの下の方の `Use cases` の方に、`Enable secure access to apps hosted on-premises or on another cloud` というリンクを見つけたので、これに則ってBeyondCorp Remote Accessの実現方法を学んでいきましょう
https://cloud.google.com/solutions/beyondcorp-remote-access

このページからリンクが張っている「オンプレ環境のアプリをセキュアにしていくぞ」というガイドがこちら [Securing on-premises apps and resources with IAP](https://cloud.google.com/context-aware-access/docs/securing-on-premises)
多分これ日本語版これだと思うのでお好きな方を参照しつつやってみましょう
[オンプレミス アプリでの IAP の有効化](https://cloud.google.com/iap/docs/enabling-on-prem-howto?hl=ja)[^2]
[^2]: これの `IAPインスタンス` ってなんだ？って思ったけど途中でロードバランサー立てて、その後にそれに対してIAPを有効化してるので、最初の時点でIAPインスタンスとやらが無い！ってなっても気にしなくて良さそう

# 構成要素の説明

### IAP(Identity-Aware Proxy)
[公式の概要ページ](https://cloud.google.com/iap/docs/concepts-overview?hl=ja)
ざっくり言うとアタッチされたリソース(GAE, HTTPロードバランサー, GCE)へのアクセスの際に、Googleログインを求めるようにしてお手軽にアプリケーションを保護する機能です。
設定[^3]でアクセス可能な人を絞れたりもするので組織内でも特定のメンバーしかアクセスできないようなアプリケーションにも対応できます
[^3]: https://cloud.google.com/iap/docs/managing-access

上のリンクにあるこちらの図がオンプレ向けにBeyondCorp Remote Accessを実現した全体図という感じがある
<img width="420px" src="https://cloud.google.com/iap/images/iap-on-prem.png?hl=ja"/>

### Cloud Interconnect
[公式の概要ページ](https://cloud.google.com/interconnect/docs/concepts/overview?hl=ja)
これに関しては使ったことがないので概要ページを読むしかできないんですが、なんかダイレクトにオフィスとGCPのNWを接続したり、ISP経由でGCPと接続したりできるらしいですね
[Interconnectが使えるISP一覧](https://cloud.google.com/interconnect/docs/concepts/service-providers?hl=ja)
(この時点で、そんなお手軽に導入できる？という気がしてきますが実際どうなんでしょう)

または拠点間をつなぐサービスだと[Cloud VPN](https://cloud.google.com/interconnect/docs/concepts/overview?hl=ja)があったと思うんですがこちらも使えそうに思いますがどうでしょう[^4](いずれにせよ使っていないのですみません)
[^4]: 少なくともInterconnectの概要ページでは言及されていますが、[こちら](https://cloud.google.com/iap/docs/enabling-on-prem-howto?hl=ja)ではInterconnectで、とわざわざ指定しているのはどういう意図なのか...

さておきこれがどういう風に利用されるかという話ですが、IAPはGCP上のロードバランサーに対してアタッチされて認証を提供するのですが、ではロードバランサーはどうやってオンプレ環境のアプリケーションに対してリクエストを届けるのか、というとInterconnect経由で通信を中継するというわけです。

### Cloud IAP Connector
これはそういうサービスがあるわけではなくてリクエストをルーティングするための一連のリソース群です。
これは、GCPのIaCサービスであるDeployment Managerによってセットアップするための定義ファイルがgithub上で公開されています。
参照している大本のガイドと、githubのリポジトリに紹介があります。
https://github.com/GoogleCloudPlatform/iap-connector

詳細は、classmethodさんのブログにわかりやすい解説があったのでそちらを見ると良いです。
[BeyondCorp Remote Accessを支える技術 #1 GCP Cloud IAP connectorを試してみた](https://dev.classmethod.jp/articles/beyondcorp-remote-access-getting-started1/)

# 注意点

基本的にはそれぞれのドキュメントに書いてあるので落とし穴というほどではないですが、俺たちもIAPでセキュアにしていくぞ、という前に改めて思い出すと良さそうなポイントをあげていきます。
## HTTPSトラフィックを受け入れるHTTPベースのアプリが必要
[オンプレミス アプリでの IAP の有効](https://cloud.google.com/iap/docs/enabling-on-prem-howto?hl=ja)に書いてあることですが、例えばTCPの独自プロトコルで通信するクライアントアプリを動かしたり、というのは難しそうです。
また、認証自体はOAuth2.0の流れに則って行われるのでHTTPベースであれば何でもOKというわけではありません(ざっくり言うとブラウザと同じようにユーザにログイン画面を見せられるソフトウェアであることが必要)
[TCP 転送での IAP の使用](https://cloud.google.com/iap/docs/using-tcp-forwarding) というドキュメントを見つけてオッと思ったのですがこれはGCEインスタンスに対してのみ有効なので少なくとも既存プロダクトの組み合わせでGCPマネージド[^1]なやり方ではオンプレとHTTP以外のプロトコルでつながる際にIAPを使うことはできなさそうです。

[^1]: 例えば頑張って更に通信を中継するようなGCEインスタンスを構築すれば実現できないことはないでしょうが、それは果たしてVPN頑張って構築、運用するのと労力的には大差ないのでは?という懸念があります。

## 利用者全員にGoogleアカウント付与できるかどうか
ここまで組織全体がGSuiteで管理されている前提で話してきましたが、保護対象のプロダクトの利用者がGoogleアカウントを持っていなければIAPの認証を通過できないので(社員だけでなく)利用者全員にアカウントを付与する必要があります。
また、そもそも組織がGSuiteで管理されていない状況だとそこからスタートする必要があり、そこがハードルになるかもしれません。
LDAPサーバと同期するための仕組みはあるようです。 https://support.google.com/a/answer/106368?hl=ja

## アプリケーションを一個ずつ対応させる必要がある
IAPに対応するには対応するIAP上で保護対象のLBが必要で、LBからはアプリケーションに対してリクエストを振り分ける必要があります。
そういう感じで、「このアプリはこのドメインで/パスでリクエスト来るからこっちに振ってね」みたいなルーティングを一個ずつ設定していく必要があるわけですが、大きな企業だとそもそもそこの対応だけでもそれなりの工数になるので「えぇ～い、手が回らんから内部のNWにVPN越しにアクセスできるようにしたろ！クライアント側は各自設定してね！」ってやった方が目の前の問題に対しての対応としては早いケースとかもあるんじゃあないかなと思います(MDMとかがあれば設定をそのまま展開できそう)

# おまけ: BeyondCorp Remote Accessを今日からやれるケース
GAEで社内向けアプリを配信していてIPアドレスで制限をかけているようなケースを想定します。
こういうケースでもいちいちIPアドレスのホワイトリストに個々人の自宅を追加するのは難しいので、IAPによるアクセス制御は有効です。
どうすればやれるのかというと、Webコンソールから対象のGAEに対してIAPのアクセス制御を実施するようにボタン押して、メンバー追加するだけです。
<img width="1464" alt="貼り付けた画像_2020_04_22_11_22.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/47979/44bfac6b-c1c3-f516-21d7-d1718f007280.png">

これなら多分今日からやれると思います。

# 感想
- IAPがGAEでも使えるので非常に便利
- これはVPNに代替する概念ではなくて、VPNをうまく管理/利用するための概念、という認識をしている
    - 利用者からVPNの存在を隠蔽するために結構な頑張りが見られる
- 名前がついているのはいいが、「どうなっているとBeyondCorp Remote Accessである」みたいなのがわかりにくい
  - IAPを使ってユーザのアクセス制御を行っていれば該当する?
  - 例えばFirebase Authenticationで全アプリに認証をかけているのは違う？
- Googleログインがロードバランサーについていればいいのか？という観点でedgeでの認証みたいなものをいくつか調べてみた
    - FastlyはVCL力が必要そうだができないことはなさそう
        - https://www.fastly.com/blog/patterns-for-authentication-at-the-edge
    - AWSはLambda@Edgeがあるので、比較的容易そう(いずれにせよIAPの方が簡単ではあるが)
        - https://aws.amazon.com/jp/lambda/edge/#User_Authentication_and_Authorization 

## チラシの裏
Q: BeyondCorp Remote Accessって何
A: Cloud IAPのことです[^6]
[^6]: または認証/認可の仕組みがついたロードバランサー