G-gen の杉村です。情報セキュリティの世界でゼロトラストというキーワードが半ばバズワードのように取り上げられるようになってから久しくなりました。Google のゼロトラスト・ソリューションとして BeyondCorp Enterprise があります。
当記事の前半では、BeyondCorp の基本的な概念や構成を説明します。後半 (第4項以降) は、BeyondCorp の各構成要素を詳細に説明しますので、技術者の方向けです。
BeyondCorp Enterprise の概要
BeyondCorp Enterprise とは
BeyondCorp Enterprise とは、エージェントレス・ VPN レスで社内 IT サービスへのアクセスを実現する、 Google のセキュリティサービス群です。
BeyondCorp Enterprise では、 VPN を使わずに、 インターネット経由で安全に社内システムや SaaS などへアクセスさせることができます。デバイスがブラウザとして Google Chrome を使っていることが条件です。
例として「会社承認のデバイスであること」「会社の Google アカウントでログインしていること」という条件を満たしていれば社内の顧客情報システムへのアクセスを許可する...といった設定が可能です。なおかつ、 IT 管理者は VPN ルーターやゲートウェイ (プロキシ) の管理をする必要がありません。
なお BeyondCorp という用語自体は、後述のゼロトラストセキュリティを実現するために Google が開発した実装モデルを指しており、BeyondCorp を一般の組織向けに販売したプロダクトが BeyondCorp Enterprise です。
ゼロトラストセキュリティとは
前述のようにユーザーのリクエストのコンテキスト（デバイス状態、アクセス状況等、 ID とパスワードだけに頼らない各種背景情報）を判断に使ってアクセス制御を行う方式はゼロトラストセキュリティと呼ばれます。Google 社では実際に、BeyondCorp の仕組みを社内で利用し、 VPN レスなゼロトラストセキュリティを実現しているといいます。
ゼロトラストセキュリティは、従来型の「社内と社外を境界線のファイアウォールや UTM で区切る」「社内ネットワークからのアクセスであれば安全とみなして、全て許可する」という 境界型ネットワーク とは、考え方が異なります。
2010 年代以降に一般的になった標的型攻撃等により、社内ネットワークにマルウェアが入り込んだり、あるいは侵入者にひとたび社内ネットワークに入り込まれると、境界型セキュリティは意味をなしません。これが、近年ゼロトラスト・セキュリティが注目されている理由です。
BeyondCorp Enterprise は Google が自社で実現したゼロトラストをサービス化したものであり、多数の実績のあるソリューションだといえます。
構成要素
BeyondCorp Enterprise は次の 4 つのコンポーネントで構成されます。
| No | 名称 | 一言で言うと | 説明 |
|---|---|---|---|
| 01 | Identity-Aware Proxy (IAP) | マネージドのリバースプロキシ | 社内サーバなどへの接続を中継してくれる、 Google Cloud 上の仕組み |
| 02 | Identity and Access Management (IAM) | Google Cloud の認証認可機構 | Google アカウントと権限を紐づける仕組み |
| 03 | Access Context Manager | ルールエンジン | デバイス情報、アカウント情報、接続状況など各種背景情報からアクセス可否を判断する仕組み |
| 04 | Endpoint Verification | エンドポイントエージェント | ユーザーのデバイス情報を収集する Google Chrome 拡張機能 |
各コンポーネントの機能を図で表すと、以下のようになります。
この図では IAP が単一障害点（SPOF）に見えてしまうかもしれませんが、 Google が管理している高度にスケーラブルなインフラのうえで稼働しているため物理的には単一障害点にはなっておらず、高い可用性を持っています。IAP の物理的な構成要素の一つである Cloud Load Balancing は月単位で 99.99% の SLA を持っています。
また、その他の機能として BeyondCorp Threat and Data Protection があります。
これは Chrome ブラウザの追加機能として提供され、マルウェアやソーシャルエンジニアリングなどのウェブ上の脅威に対する保護や、 Data Loss Prevention (DLP) ルール、セキュリティアラート、レポートツールを利用できるようになります。
運用
ID（ユーザーアカウント）
認証に用いられる ID（ユーザーアカウント）は、原則として Google アカウントです。
Google アカウントは Google Workspace または Cloud Identity で管理されます。
外部 ID 連携
外部 ID 連携機能を用いることで、以下のような外部 ID を Google アカウントと連携して認証が可能になります。
- メール / パスワード
- OAuth (Google, Facebook, Twitter, GitHub, Microsoft など)
- SAML
- OIDC
- 電話番号
- カスタム
- 匿名
監査ログ
デフォルトでは、アクセスポリシー違反をしたログは、全て Cloud Audit Logs の仕組みにより記録されます。
追加の手順を実行することで、全てのリクエストを詳細にログ出力させることも可能です。
ログは Google Cloud のコンソールにて操作対象を「組織」にすることで Cloud Logging の Log Explorer を使うことなどによって閲覧できます。BigQuery へのエクスポートなどにより、より深い分析も可能です。
Cloud Audit Logs や Cloud Logging の詳細については、以下の記事をご確認ください。
料金
BeyondCorp Enterprise の料金
BeyondCorp Enterprise の料金 は 1 ユーザーあたり月額 $6 (約 660円) です。
BeyondCorp Enterprise へのアップグレードはコンソール等からはできないため、 Google もしくは販売パートナーの担当営業へお問い合わせください。その際に利用人数を申請しますが、その申請ベースでの課金となります。
その他の課金
利用人数ベースの課金のほか、 BeyondCorp Enterprise の使用に伴いデプロイされた Cloud Load Balancing などに料金が発生します。
また ID 管理のための Google Workspace や Cloud Identity（Premium の場合）のアカウント料金も別途発生することに注意が必要です。
無料範囲
Google Cloud では IAP が無料 で利用できます。
ただし無料で利用できるのは、転送対象が Google Cloud 内のみである場合や、アクセス制御に IP アドレスのみを使う場合です。オンプレミスのアプリへの転送や、デバイス情報を使ったアクセスレベルの設定などは、有償の BeyondCorp Enterprise を使う必要があります。
すぐに活用できる場面としては Google Compute Engine (GCE) の VM への SSH / RDP ログインが挙げられます。無料範囲の IAP を活用することで 踏み台サーバ無しで VM へのログインが実現でき 、非常に便利です。使い方については、以下の記事をご参照ください。
技術的な詳細解説
ここまでは、 BeyondCorp Enterprise の基本的な概念を解説しました。
ここからは技術的な観点から、 BeyondCorp の構成要素を深堀りしてご紹介します。
01. Identity-Aware Proxy (IAP)
Identity-Aware Proxy (IAP) とは
Identity-Aware Proxy (IAP) は、 フルマネージドのリバースプロキシ です。簡単に言うと、社内システムへの接続を中継してくれる、 Google Cloud 上の仕組みです。
「フルマネージド」というのは、 この仕組みが Google の管理するインフラの上で動いているため、インフラ管理・運用をする必要がないということを意味しています。
IAP が中継するのは基本的には HTTP(S) トラフィックですので、 Web アプリケーションが利用対象となります。IAP が中継を許可するかどうかは、後述の IAM や Access Context Manager で定義したルールに基づいて判断されます。つまりインターネットから社内システムへアクセスする際、ユーザー情報やデバイス情報に基づいてアクセス可否が判断されるため、安全に利用することができます。
この IAP のおかげで、 Internet VPN に頼らないセキュリティを構築できるのです。
オンプレミスのアプリの中継
IAP が中継する Web アプリは、 Google Cloud 上に Google Compute Engine (GCE) や Kubernetes Engine (GKE) で構築されたものでもよいですし、オンプレミスにあるものでも可能です。
オンプレミスの Web アプリを中継する場合、 コネクタ（オンプレミスコネクタ）をデプロイする必要があります。コネクタの実体は、Cloud Load Balancing の External HTTPS ロードバランサーと Google Kubernetes Engine（GKE）でホストされたサービスです。
コネクタからオンプレミスの Web アプリへの通信は、暗号化プロトコルであればインターネット経由でもリスクは低いといえます。
非暗号化プロトコルの場合は Google Cloud の VPC とオンプレミス環境が Cloud Interconnect（専用線）やインターネット VPN で接続されているべきです。
02. Identity and Access Management (IAM)
Identity and Access Management は略称を IAM といい、認証認可の仕組みです。特にクラウドサービスでは一般的な用語です。
IAM は「誰 (プリンシパル、主体) が、どういう 条件 (コンディション) のもとなら、 何に対して (対象リソース) 、 何をできる (ロール、権限)」というルールセットを管理する仕組みです。
Google Cloud の IAM の特徴として「誰 (プリンシパル、主体) が」「どういう条件 (コンディション) のもとなら」「何をできる (ロール、権限)」という情報を、 操作対象のリソースに紐づける 形になっています。この紐付けを バインディング (binding) と呼びます。バインディングは IAM policy と呼ばれる形で、各リソースの属性として保持されます。
BeyondCorp では、 IAP に設定した社内リソースに対して IAM policy を設定し、「誰 (プリンシパル、主体) が」「どういう条件 (コンディション) のもとなら」「何をできる (ロール、権限) = どのサービスに対して接続できる」という細かいアクセス制御が実現可能です。
Google Cloud (旧称 GCP) の IAM の仕組みについては、以下の記事で詳細に紹介しています。さらに深堀りして理解したい方はご参照ください。
03. Access Context Manager
Access Context Manager とは
Access Context Manager は、デバイス情報、アカウント情報、接続状況など各種背景情報からアクセス可否を判断する仕組みです。
Access Context Manager は IAM とセットで使われます。 IAM の「条件 (コンディション) 」として Access Context Manager が使われるイメージです。
Access Context Manager で定義する条件設定を アクセスレベル と呼びます。アクセスレベルでは、以下の要素を条件として利用できます。
- [A] IP アドレスレンジ
- [B] 地域
- [C] プリンシパル (主体)
- [D] デバイスポリシー
[A] IP アドレスレンジ
IPv4 および IPv6 の IP アドレスを、 CIDR 形式 ( x.x.x.x/x ) で指定できます。
パブリック IP のみを指定できます。
[B] 地域
アクセス元 IP アドレスから地理情報が判断され、指定した地域からのアクセスのみが許可されます。 条件に複数地域を指定すると、OR で判定されます。
なおパブリック IP アドレスから判定されるため、地域を条件に指定すると、 Private Google Access（限定公開の Google アクセス）等を使ったプライベート IP アドレスからのアクセスは拒否されます。
[C] プリンシパル (主体)
アクセスに使われるプリンシパル (Google アカウントやサービスアカウント) です。
そもそも IAM policy は Google アカウントや Google グループ、サービスアカウントと紐付けられて作成されるので、条件の中でプリンシパルを指定することは限定的かもしれません。
同じグループに紐付いている IAM policy で、プリンシパルによって条件を少し変えたい、というときに利用することがあるかもしれません。
[例] ops-grp@example.com <=> システム A への IAP アクセスを許可する IAM policy がある。その policy の条件に「 tom@example.com は 09:00-18:00 の時間帯でアクセスを許可」「 mary@example.com は 18:00-09:00 の時間帯でアクセスを許可」と設定
なお IAM の condition にプリンシパルを追加することは、コンソールからはできません。gcloud コマンド等での作業が必要です。
[D] デバイスポリシー
後述の Endpoint Verification で取得されたデバイスポリシーと合致しているかを条件にできます。以下の要素を条件としてチェックできます。
- スクリーンロックの強制
- ストレージ暗号化
- デバイスが管理者に承認されていること
- 会社指定のデバイスであること
- 会社指定の OS であること
これにより、会社指定の端末以外がサービスに接続することを防いだり、セキュアでない設定となっている端末がサービスに接続してくることを防ぐ事が可能です。
04. Endpoint Verification
Endpoint Verification (エンドポイント・ベリフィケーション) は Google のブラウザである Chrome の拡張機能 (Extention) を使い、ユーザー情報や端末の情報を収集します。
つまり各 PC の Chrome ブラウザに拡張機能をインストールする必要があるのですが、 Google Workspace を利用している場合は Endpoint Verification Chrome extension を管理コンソールから一斉配布・自動展開が可能です。
その他の機能
BeyondCorp Threat and Data Protection
前述の主要な4つの構成要素とは別で BeyondCorp Threat and Data Protection 機能が存在します。
これは Chrome ブラウザの追加機能として提供され、マルウェアやソーシャルエンジニアリングなどのウェブ上の脅威に対する保護や、 Data Loss Prevention (DLP, データ損失防止) ルール 、セキュリティアラート 、レポートツール を利用できるようになります。
DLP 機能 では、 Chrome 上で機密データの共有に関して警告を出したりブロックしたりします。
ファイルのアップロード/ダウンロードや、コピー&ペーストの中に、クレジットカード番号や大量のメールアドレスが含まれている場合などに当機能が働き、ブロック / アラート などを行うことができます。ただし、この機能は Windows 、 Mac 、 Linux 、 Chrome OS の Chrome ブラウザでのみ機能する ことに注意が必要です。
また、 監査ログ・セキュリティダッシュボード・レポート 機能も充実しています。
「Chrome の脅威対策に関する概要」「Chrome のデータ保護に関する概要」「リスクの高い Chrome ユーザー」「リスクの高い Chrome ドメイン」などのレポートを表示することができ、マルウェアの転送、危険なサイトへのアクセス、パスワードの再利用、機微なデータの転送などのアクティビティを可視化できます。
従業員の活動を Chrome ブラウザに集約・制限したうえで BeyondCorp Threat and Data Protection をうまく活用することで、情報漏洩のリスクを大幅に下げる事が可能です。
Cloud Console / Google Cloud API へのアクセス制御
見逃されがちな機能ですが、 Google Cloud の Web コンソールや、コマンドライン / SDK を使った Google Cloud API への アクセス制御 も行うことができます。
この機能を使って、Google Cloud 環境の運用者や開発者に対し、接続元 IP アドレスやデバイスポリシーに基づいたアクセス制御をかけることができます。
アクセスレベルの定義に違反する運用者は、コンソール画面にアクセスできませんし、 CLI を使って環境を操作することもできません。
杉村 勇馬 (記事一覧)
執行役員 CTO / クラウドソリューション部 部長
元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。
Follow @y_sugi_it