【GCPでセキュリティの柱を築く】Chrome Enterprise Premiumでマネジメントコンソールへのアクセスを制限する
こんにちは。クラウドアーキテクトの山下です。
Google Cloud組織でセキュアな環境を作るために今回はChrome Enterprise Premium(旧BeyondCorp)について触れていきたいと思います。
Google Cloudをはじめとしてパブリッククラウドは文字通りインターネットで公開、サービス提供されているIaaS/PaaSになります。IAMによる認証/認可でアクセス制御を行う事が出来るものの、ネットワークの通信制御は別途行われない限り、どの端末からでもどの場所からでもクラウドにアクセス出来てしまいます。
そのため、個人端末からクラウドにアクセスしてクラウド上のストレージやデータベースからデータを閲覧したり、最悪流出させてしまう危険性があります。また、Googleアカウントの認証情報が奪われ侵入された場合も以降は成す術がなくなってしまいます。
クラウド利用者の善意に頼ってしまうと思わぬ事故を招いてしまったり、悪意のあるメンバーが加わってしまった場合に内部から攻撃される余地を作ってしまいます。
これを防ぐものとしてGoogle Cloud ではChrome Enterprise Premiumが提供されています。これによって特定端末やIPアドレスからのみのアクセスを許可し制限する事が可能です。
ネットワークの到達可能性(Reachablity)までは物理的に防ぐことはできませんが、条件に合致しない通信をネットワークレベルでブロックする事ができます。AWS/Azureと比較しながらこちらの理解を深めてセキュアな環境を目指しましょう！
※2024年6月現在はBeyondCorpからChrome Enterprise Premiumへ命名が変更したばかりなのもあり、ドキュメントにBeyondCorpと表記されている場合もありますが同義と捉えて問題ございません。
Chrome Enterprise Premiumで出来るアクセス制御
以下大きく4つの機能を提供しています。
| 機能 | 内容 |
|---|---|
| Identity and Access Management(IAM) | 認可/RBACを行う基本機能。Googleアカウントに対して権限の付与(ロールバインド)を行う |
| Idenity-Aware Proxy(IAP) | IAMの認証を基にGoogle Cloudサービスに間接的にアクセスする |
| Access Context Manager(ACM) | アクセス経路(送信元)の情報を精査し、アクセス制御を行う |
| Endpoint Verification | 接続する端末情報を収集しアクセス元をさらに厳しく制限する |
IAM条件
IAMはGoogleCloudを利用する上で必須のため、Chrome Enterprise Premium用に追加で何か設定するものではありませんが、ドキュメントにも記載の通りConditions(IAM条件)でより細かく制御もできます。
例：特定のサービス(API)しかアクセスさせない場合
IdentityAwareProxy
IAPはGCEへのSSHなどIAMに登録された認証と認可を用いて間接的にアクセスできるサービスです。AWSのSystemsManagerのSessionManagerとほぼ同等の機能です。Google CloudのAPIで認証し、文字通りAPIをプロキシとしてGCEにログインする事が出来ます。
IAPは明示的に設定せずともファイアウォールルールでGoogleのAPIからアクセス出来るよう設定する事とアクセスに必要な権限を有している事、条件で制限がない場合に利用出来ます。
GCEのコンソール上にあるSSHボタンやgcloudコマンドでのSSHが良い例です。
一方、AWSやAzureと大きく異なるのはAPIからHTTPSで接続されているのではなく、実際にSSH/RDPで接続されているという点です。また、VPC/VNETのエンドポイントを介した場合は送信元はVPCのCIDRとなりますが、Google Cloudにエンドポイントという概念は存在しないのでGoogleが管理しているAPIのセグメントを指定する必要があるという点です。
実施方法
ネットワークのファイアウォールルールにて以下の設定を入れます。
- 送信元IPv4範囲：35.235.240.0/20
- 送信元ポート番号：22(SSH),3389(RDP)
IAM権限を以下の方法で追加する
- Googleアカウント/グループに直接”**compute.instances.get”**を持つ事前定義ロール(Compute 管理者など)かカスタムロールをロールバインドする
- Googleアカウント/グループに直接”**iap.tunnelDestGroups.accessViaIAP”,”iap.tunnelInstances.accessViaIAP”**を持つ事前定義ロール( IAP で保護されたトンネル ユーザーなど)かカスタムロールをロールバインドする
- または、Identity-Aware ProxyのSSHとTCPのリソースより”プリンシパルを追加”でリソース単位で権限を付与する。
AccessCotextManager(ACM)/Endpoint Verification
ACMはChrome Enterprise PremiumだけでなくVPC ServiceControlsにも用いられるコアサービスです。実質このサービスでアクセス制御を定義出来ると言っても過言ではありません。
AWSではIAMロール内のCondition句、AzureではEntraIDの条件付きアクセスで制御しますが、GoogleCloudでは独立したリソースとしてまとめて定義する事が出来ます。そのため、後からアクセス条件を変更したり、アクセス条件を使いまわす際に運用上のメリットがあります。
ACMでは以下をアクセス制御に組み込めます。
- アクセス元IPアドレス
- アクセス元地域
- アクセス元デバイスポリシー(※端末)
特定の国からのみのアクセスに制限したり、アクセス元のIPアドレスを限定することが出来ます。
また、Premiumライセンスではデバイスポリシーを使う事ができます。IPアドレスやロケーションレベルではなく特定の端末からのみのアクセスに限定するより強力な制限をかける事が出来ます。
IPアドレス制限は今までPremiumライセンス抜きに利用できなったプライベートIPを指定することが可能になりました。閉域網で接続したオンプレミスと接続するVPCからのみの接続に限定したいようなユースケースはこちらを用いる事でも代用できます。
アクセス制御を実装する
今までアクセス制御方法について触れてきましたが、実際にアクセス制御を適用してみましょう。
まず準備としてあらかじめGoogleグループをCloudIdentityもしくはGoogleCloudコンソール上から作成します。また、組織が構成されていることが大前提となります。
操作には以下の権限またはその権限を持つ以下の事前定義ロールが対応者に付与されている必要があります。
次にChrome Enterprise Premiumから「CloudコンソールとAPIへのアクセスを管理」をクリックします。
特に何も設定していない場合、GoogleCloudのコンソールへはどこからでもアクセスできる状態になっています。「アクセスを管理」をクリックしてアクセス制御を加えます。
つぎに「追加」をクリックします。
アクセス制御対象を行うグループとAccessContextManagerの設定を紐づけして「保存」します。
ここで注意なのが、設定画面に表示されている通り、グループとACMを紐づける事でグループのアクセスを制限は出来ます。一方で、グループに所属していないGoogleアカウントがIAMロールを組織やプロジェクトでバインドされてしまうとアクセス制御が効きません。
Cloud Identityでグループを作成し必ずグループにユーザーを所属させる。グループ単位でIAMロールバインドを行う運用が必要になるので、そこを飛ばすとアクセス制御が効かないままとなってしまいます。
これを設定する事でACMで決められた条件を満たした場合のみ、認証認可が行われコンソールやAPIへの操作を行えるようになります。
まとめ
AWS/Azureでベストプラクティスとされるアクセス制御については本日触れた内容で満たすことが出来ます。一方で、MFAやドメイン制御はCloud Identityや組織ポリシーで行われるものになります。
ACMでアクセス制御設定を一元管理できるため、設定の見直しや全体への再適用が非常にスムーズに行う事が出来ます。さらにIAPについてもACMと組み合わせてより細かくアクセス制御をかける事も出来ます。IAMロールも条件を設けてグループ単位でアクセスできるサービスを絞る事も可能です。
一点注意なのが、IAMロールのバインドが無制限に行われている場合、これらのアクセス制御が全て台無しになってしまう点です。ServiceAccountを除くGoogleアカウントやGoogleグループの払い出しやロールバインドはプロジェクトのユーザーに渡さず、特定の管理者だけに委ねる運用とする等して統制を効かる必要があります。
Chrome Enterpriseと組み合わせてアクセス制御をよりセキュアなアカウントを目指しましょう！
Discussion