ピクシブにおけるBeyondCorp Remote Accessの活用事例

概要

こんにちは、インフラ部のkoboです。

感染症の流行を受けて、ピクシブでは2020年春から自宅でも仕事ができる体制を継続しています。その少し前から、ピクシブでは社内サービスへのVPNレスなアクセスを可能にするための堅牢なSSOプロキシの導入を進めていました。それはGoogleがBeyondCorp Remote Accessと呼んでいる仕組みです。ピクシブでは今もオンプレミスで動作する社内システムが多く存在していますが、これのおかげでほとんどの業務をVPNを使用することなく自宅でこなすことができています。

本記事では、BeyondCorp Remote Accessの概要と、ピクシブでの運用事例について紹介します。

BeyondCorp Remote Accessとは

BeyondCorp Remote Accessとは、GCPのIdentity Aware Proxy (IAP) を利用してオンプレミスまたは他のクラウド上のサービスを保護するアーキテクチャのことです。 IAPは元々はGCP上にホストされたサービスの認証のために用いられるものですが、このアプローチでは、これを拠点間VPNやCloud Interconnectで接続した別の拠点上にホストされたサービスへの保護に使用しています。

(出典: https://cloud.google.com/solutions/beyondcorp-remote-access )

これにより、ピクシブでは次のことが実現できました。

オンプレミスや他のクラウドサービスにホストされた社内サービスへのGoogle認証を通じたVPNレスなアクセス

社内LANやVPNなどネットワークの境界に基づいたアクセス制御の代わりに、Google認証を要求するプロキシを通じて社内サービスにアクセスできるようにしました。 Google Workspaceへのログインは組織のポリシーにより2FAが必須になっていますが、社内システムへのアクセスにおいてもこれと同じレベルのセキュリティを実現できています。

エッジ、SSL証明書、ロギングなど構成要素のフルマネージド化

GCPのマネージドなロードバランサがエッジになるため、何らかのSSOプロキシを自分で構築する方法と異なり、インターネットに面したウェブサーバを自分で運用する必要がありません。これによりアタックサーフェスを減らすことができています。
また、SSL証明書はGCPのマネージド証明書を利用することで更新作業を不要にしています。
更に、ロギングは複雑な設定をせずともCloud LoggingとBigQueryに流し込むことができています。
アクセスログには使用したGoogleアカウントの情報も記録されるため、いつ、どこから、誰が、どのシステムでどういった操作をしたかの記録が残り、これを監査ログとして使うことができます。

また、次のことはまだ実現できていませんが、今後の実現に向けて取り組んでいます。

Context Aware Accessを活用したユーザー・デバイス両方を認証するゼロトラストなアクセス制御

IAMの認証に加えて、Context Aware Accessを活用することで、以下が可能になります。

Google WorkspaceアカウントまたはGoogle Group単位でのアクセス制御
アクセス元端末のIPアドレス、地域、端末の設定情報 (ディスク暗号化、パスワードロック、Google Workspace上での承認状況) に基づいたアクセス制御

この2点により、ゼロトラストネットワークの要件であるところの「ユーザー」「端末」両方の認証認可を行うことができます。

構成

BeyondCorp Remote Accessを構成するためのサンプル実装、iap-connectorがGoogleから提供されています。このリポジトリはGCPの公式ドキュメントからも参照されています。

iap-connectorとは、Ambassador API Gatewayをリバースプロキシとして使用するGKEクラスタです。TLS終端や認証認可、ロギングをCloud Load Balancingで行い、Load Balancerを通過したリクエストをAmbassadorが受け取り、適切なバックエンドにリバースプロキシします。Ambassadorからバックエンドへの経路は、Cloud VPN / Cloud Interconnectを経由してプライベートネットワークに入る場合もあれば、Cloud NATを経由してインターネットに出る場合もあります。

運用

構成管理

ピクシブでは、上記のiap-connectorリポジトリに含まれているTerraform / Helm実装を元にカスタマイズしたものを使用しています。 TerraformとHelmのコードはそれぞれ別のリポジトリに分離し、それぞれでCI/CDパイプラインに乗せてデプロイしています。構成に必要なGCP上のリソース (GKEクラスタ、SSL証明書、DNS、外部IPアドレス、NAT、IAM roles、...) はほぼ全てTerraformとHelmで管理しており、Infrastructure as Codeが実現できています。

アクセス管理

IAPでは、主にユーザー、Google Groups、GCPのサービスアカウントの単位でアクセス権限を付与することができます。

ピクシブでは、各サービスごとにアクセス権限管理用のGoogle Groupを発行し、その中に個別のユーザや部署のグループを入れることでアクセス権限を付与しています。
こうすることで、Google Groupsを管理する操作で社内システムへのアクセス管理ができるようになり、部署グループ単位で権限を付与することで社員の異動に合わせて自動的にアクセス権限が付与/剥奪されるようにしたり、必要に応じてGroupの管理権限を事業部に委譲することで社内システムへのアクセス管理権限も委譲することができています。

その他、プログラム用にサービスアカウントを発行して、それに対してiap-connectorの認証を通過する権限を付与することができます。これは、外部からインターネット越しに特定のAPIを叩く必要があるプログラムがある場合などに役に立ちます。

どのサイトにどのユーザー / グループ / サービスアカウントのアクセスを許可するか、といった情報 (IAM roles) はYAML形式のコードで管理されており、これはデプロイフローの中で自動的に適用されるようにしています。

困ったこと

GCPのLoad Balancerは、ワイルドカードドメイン指定でのルーティングができません。ピクシブの一部の開発環境などでは、バックエンドのHostのサブドメインが動的に生成されるような仕組みがあるためにワイルドカード指定が必要な場面があり、これはiap-connectorで対応することができませんでした。

ピクシブでは以前よりoauth2-proxyというOSSのSSOプロキシを使用しており、より堅牢で多機能なiap-connectorへの移行を進めてきましたが、対応できない一部の箇所では依然oauth2-proxyを使用しています。