このドキュメントでは、Linux 仮想マシン（VM）インスタンスへの SSH ネットワーク アクセスを制御する際のベスト プラクティスについて説明します。
SSH を使用して VM インスタンスに接続するには、VM インスタンスへのネットワーク アクセスと有効な SSH 認証情報が必要です。デフォルトでは、Compute Engine は、SSH ネットワーク アクセスを制限しないファイアウォール ルールを使用します。このルールでは、インターネット上の誰もが VM インスタンスのポート 22 に接続できます。ネットワークやセキュリティ管理を検討せずにすぐに始めることができるため、これはデベロッパーにとって便利ですが、ユーザーが任意のデバイス、ネットワーク、ロケーションから接続できるようにすると、次のようなリスクがあります。
- ユーザーが信頼できないデバイスやネットワークから接続する可能性がある。
- 不正な行為者が総当たり攻撃を実行し、VM インスタンスを侵害しようとする可能性がある。
- 漏洩した SSH 認証情報にアクセスできる不正な行為者が、その認証情報を悪用して、任意のネットワークから VM にアクセスしてログインする可能性がある。
以降のセクションでは、ユーザーが VM への SSH 接続を確立できるネットワーク、ロケーション、デバイスを制限することでリスクを軽減する方法について説明します。
このドキュメントでは、Google Cloud に固有のプラクティス、または Google Cloud で SSH を使用する場合に特に関連性の高いプラクティスに焦点を当てて説明します。このドキュメントでは、特定の SSH クライアントまたはサーバーの実装に関するベスト プラクティスについては説明しません。
ネットワークへの露出を減らす
ユーザーがどこからでも SSH 接続を確立できるようにすると、VM の保護に SSH の認証と認可のメカニズムに完全に依存することになります。VM のネットワークへの露出を減らすことで、リスクを軽減し、追加の保護レイヤを確立できます。
VM のネットワークへの露出を減らす方法はいくつかあります。ご使用の環境に最適なアプローチを特定するには、次のフローチャートで説明されているように、いくつかの要素を考慮する必要があります。
外部アクセス: 最初に考慮すべき要素は、VM に VPC ネットワーク内からのみアクセスする必要があるのか、外部からもアクセスする必要があるかです。
VPC 内部からのアクセスで十分な場合は、VM に外部 IP アドレスを割り当てる必要はありませんが、アクセスの管理方法を決める必要があります。
内部ネットワークのサイズ: VPC 内部からのアクセスで十分な場合は、内部ネットワークのサイズも考慮する必要があります。
小規模なネットワークでは、内部アドレスからポート
22への上り（内向き）を許可するファイアウォール ルールを使用して VM を保護するだけで十分な場合があります。大規模なネットワークでは、ファイアウォール ルールのみに依存すると制限が厳しすぎる場合があります。このような場合は、Identity-Aware Proxy TCP 転送を使用して、VM へのコンテキストアウェア アクセスを適用できます。VPC Service Controls の境界設計: 次に考慮すべき要素は、VM インスタンスが VPC Service Controls の境界の一部かどうかです。
VM がサービス境界の一部である場合、VM から発信された API アクセスは境界内から発信されたと見なされます。境界外のユーザーに境界内の VM への SSH アクセス権を付与すると、境界からローカルのワークステーションにデータをコピーしたり、その逆の操作を行うことが可能になり、境界内のデータの機密性と完全性が危険にさらされる可能性があります。
VPC Service Controls 境界内の VM インスタンスに SSH アクセス権を付与する必要がある場合は、IAP TCP 転送を使用します。IAP は、ユーザーのワークステーションが同じ VPC Service Controls 境界に属しているかどうかを識別し、デフォルトでは、サービス境界外からのアクセスをブロックします。外部アクセスを許可するには、上り（内向き）ルールを使用して、コンテキストアウェア アクセスを適用するように構成します。
クライアント デバイスの管理: 最後に考慮すべき要素は、クライアント デバイスの管理方法です。これによって、コンテキストアウェア アクセスを制御する方法が決まります。
コンテキストアウェア アクセスは、Access Context Manager がユーザー、デバイス、ロケーションに関する豊富なシグナルにアクセスでき、Chrome Enterprise Premium と連携して機能する場合に最も効果を発揮します。Chrome Enterprise Premium を使用してデバイスを管理する場合は、デバイスの状態に基づいてアクセスを制御するアクセスレベルを設定できます。次に、IAP TCP 転送とアクセス バインディングまたは IAM 条件を組み合わせて、このアクセスレベルを SSH アクセスに適用できます。
クライアント デバイスの構成を制御していない場合は、そのデバイスを管理対象外のデバイスとし、信頼できない可能性があるとみなす必要があります。
管理対象外のデバイスからのアクセスを許可するには、IAP TCP 転送を使用することもできますが、ユーザーの ID とデバイスの IP アドレスに基づいてのみアクセスを管理することもできます。Access Context Manager はデバイスのシグナルにアクセスできないため、デバイスの状態に基づいてアクセスを制限することはできません。
このフローチャートに従って要因を検討することで、環境でネットワークへの露出を減らすために最適な方法を特定できます。以降のセクションでは、これらのアプローチについて詳しく説明します。
IAP ベースの SSH アクセス
このアプローチの考え方は、IAP TCP 転送を介して SSH アクセスのみを許可し、IAP がユーザーの ID に基づいてアクセスを制御できるようにすることです。
次の条件に該当する VM インスタンスには、このアプローチをおすすめします。
- VM インスタンスが、外部または大規模な内部ネットワークからアクセスできるようにする必要がある。
- VM が VPC Service Controls の境界内にない。
デフォルトでは、外部 IP アドレスを持つ VM インスタンスに SSH アクセスが許可されます。これは、デフォルトのファイアウォールが公共のインターネットからポート 22 への接続を許可するためです。ただし、これは推奨されるアプローチではありません。この方法では、VM が次のような攻撃の対象となるリスクが大幅に高まります。
- 取り消されていない認証情報の使用: 退職した従業員のアクセス権が完全に取り消されていない場合、その人物が引き続き VM にアクセスする可能性があります。
- 有効な認証情報の不正使用: 不正な行為者が、盗まれた認証情報や漏洩した認証情報を入手し、それを使用してログインする可能性があります。
- サービス拒否攻撃: 不正な行為者が、リクエストを大量に送信して VM のリソースを使い果たそうとする可能性があります。
VM インスタンスへの外部 SSH アクセスを有効にするより安全な方法は、IAP TCP 転送を使用することです。踏み台インスタンスやリバース プロキシと同様に、IAP TCP 転送はクライアント デバイスと VM の仲介者として機能します。
IAP TCP 転送は、ユーザーが SSH 接続を確立しようとしたときに、次の 4 つの機能を実行します。
- 認証: IAP は、ユーザーが有効な Google 認証情報を所有していることを確認します。
- 認可: IAP は IAM ポリシーをチェックし、IAP 経由で VM に接続する権限がユーザーに付与されていることを確認します。
- コンテキストアウェア アクセス: 必要に応じて、IAP はユーザー、デバイス、ロケーションが特定のアクセスレベルを満たしていることを確認できます。
- 監査: データアクセス ログが有効になっている場合、IAP は VM インスタンスへの接続の成功と失敗をそれぞれログに記録します。
IAP がこれらの機能を仲介者として実行することで、VM に外部 IP アドレスを割り当てる必要がなくなり、セキュリティが強化されます。
IAP ベースのコンテキストアウェア SSH アクセス
このアプローチの考え方は、IAP TCP 転送を介してのみ SSH アクセスを許可し、IAP がユーザーの ID と追加の要因に基づいてアクセスを制御できるようにすることです。
次の条件に該当する VM インスタンスには、このアプローチをおすすめします。
- VM インスタンスが、VPC の外部と VPC に接続されているネットワークからアクセスできるようにする必要がある。
- VM が VPC Service Controls の境界内にない。
- VM が、特定のデバイス、ネットワーク、または位置からアクセスできるようにする必要がある。
ユーザーに（直接または IAP を介して）VM インスタンスへの SSH アクセス権を付与すると、デフォルトでは、ユーザーは任意のデバイス、ネットワーク、ロケーションから VM インスタンスにアクセスできます。ユーザーにとっては便利ですが、ユーザーが侵害されたデバイスや信頼できないネットワークから接続する可能性があるため、このようなアクセスレベルはリスクを高めます。
リスクを軽減するには、ユーザーが特定のデバイスまたは場所からのみ VM インスタンスにアクセスできるように IAP TCP 転送を構成します。このようなコンテキストアウェア アクセスは、次の 2 つの方法で構成できます。
アクセス バインディング: アクセス バインディングを使用して、アクセスレベルを作成し、グループに割り当てることができます。アクセス バインディングは、フォームまたは ID ベースのポリシーであり、ユーザーがアクセスしようとするすべてのリソースに適用されます。これは IAP だけでなく、他の API や Google Cloud コンソールにも適用されます。
アクセス バインディングを使用すると、コンテキストアウェア アクセスをリソース全体で一貫して適用できます。
IAM 条件: IAM 条件を使用してアクセスレベルを作成し、個々の IAM ロール バインディングに割り当てることができます。
IAM ロール バインディングの使用は、リソースベースのポリシーの一種です。この方法は、さまざまな VM セットに異なるポリシーを適用する場合に最適です。
基本アクセスレベルでは、ネットワークまたは地理的位置に基づいてアクセスを制限できます。Chrome Enterprise Premium のサブスクライバーは、認証情報の強度、認証に使用されるブラウザの構成、デバイスの状態などの属性に基づいてアクセスを制限することもできます。
VPC Service Controls ベースの SSH アクセス
このアプローチのアイデアは、IAP TCP 転送を介して SSH アクセスのみを許可し、特定のソースの ID に対して IAP 上り（内向き）を許可するようにサービス境界を構成することです。
VPC Service Controls の境界に含まれる VM インスタンスに対しては、このアプローチをおすすめします。
サービス境界の一部である VM に対する外部 SSH アクセスをユーザーに許可すると、ユーザーが SSH を介してデータを流出させ、VPC Service Controls 境界が侵害される可能性があるため、この方法にはリスクがあります。
IAP TCP 転送を介して SSH アクセスのみを許可することで、このリスクを軽減し、すべての SSH アクセスが VPC Service Controls 境界の構成に従うようにします。
- ユーザーがサービス境界の外部から接続しようとすると（前述の例のように）、IAP TCP 転送は、VM に対する IAM 権限がユーザーに付与されているかどうかだけでなく、リクエストが境界の上り（内向き）ルールを満たしているかどうかも確認します。
ユーザーがサービス境界内から接続しようとすると、IAP TCP 転送は、VM に対する IAM 権限がユーザーに付与されているかどうか確認しますが、VPC Service Controls の上り（内向き）ルールは無視します。
次のいずれかに該当する場合、IAP は接続がサービス境界内から発信されたと見なします。
- 送信元 IP が、サービス境界に含まれる VM の外部 IP アドレスである。
- 接続が、サービス境界の一部である VM から限定公開の Google アクセスを介して行われている。
- 接続が、サービス境界の一部である Private Service Connect アクセス エンドポイントを介して行われている。
ファイアウォールで制御される内部 SSH アクセス
このアプローチの考え方は、すべての外部アクセスを禁止し、VPC 内部の SSH アクセスのみを許可することです。
この方法は、次の条件に該当する VM インスタンスに使用できます。
- VM インスタンスに外部からアクセスする必要がない。
- VM が小規模から中規模の内部ネットワークに接続されている。
- VM が VPC Service Controls の境界内にない。
外部からのアクセスをすべて禁止するには、次のいずれかを行います。
- 外部 IP アドレスなしで VM インスタンスをデプロイする。
- VPC の外部の IP 範囲からの上り（内向き）SSH トラフィックが許可されないように、ファイアウォール ルールを構成する。
シリアル コンソール アクセスを無効にする
機能していない VM インスタンスのトラブルシューティングを行うには、Compute Engine では、SSH ゲートウェイ ssh-serialport.googleapis.com を介してインスタンスのシリアルポート コンソールに接続します。このゲートウェイは、インターネット経由で一般公開されます。
SSH ゲートウェイは、VPC ネットワークではなく、基盤となるハイパーバイザを介して VM にアクセスします。したがって、シリアル コンソールへのアクセスは、ファイアウォール ルールではなく、IAM ポリシーによって制御されます。
ユーザーが VM シリアル コンソールにアクセスできるようにすると、VM が意図せず過剰に露出する可能性があります。この過剰な露出を防ぐには、compute.disableSerialPortAccess 組織のポリシー制約を使用してシリアル コンソール アクセスを無効にし、VM のシリアルポートへの緊急アクセスが必要な場合に制約を一時的に解除します。
セッションの記録が必要な場合は踏み台 VM を使用する
IAP TCP 転送は、クライアント デバイスと VM の間の中継として機能します。通常は、踏み台インスタンスまたはジャンプ サーバーによって実行される機能を実行します。このような機能には、次のものが含まれます。
- アクセス ポリシーを一元的に適用する
- アクセスを監査する
一部の踏み台インスタンスとは異なり、IAP TCP 転送では SSH 接続は終端されません。IAP TCP 転送を介して VM に SSH 接続を確立すると、クライアントと VM の間で SSH 接続がエンドツーエンドで暗号化されます。このエンドツーエンドの暗号化のため、IAP TCP 転送では SSH セッションの内容を検査できず、セッションの記録機能も提供されません。IAP 監査ログには接続メタデータが含まれますが、セッションの内容に関する情報は含まれません。
セッションの記録が必要な場合は、踏み台 VM を使用します。
- SSH 接続を終了してその内容を記録するように踏み台 VM を構成します。SSH ポート転送の使用は制限してください。セッション記録の有効性が低下する可能性があります。
- SSH 接続が踏み台 VM からのみ許可されるように、ターゲット VM のファイアウォール ルールを設定します。
- IAP TCP 転送のみで踏み台 VM へのアクセスを許可する
ファイアウォール ポリシーを使用して SSH の公開を制限する
環境に最適な SSH の露出の制限方法を決定したら、すべての VM とプロジェクトがそれに応じて構成されていることを確認する必要があります。特に、すべてのプロジェクトで、SSH の使用方法を決定する一貫したファイアウォール ルールセットを使用する必要があります。
複数のプロジェクトにファイアウォール ルールのセットを適用するには、階層型ファイアウォール ポリシーを使用して、リソース階層のフォルダに適用します。
たとえば、すべての SSH アクセスが IAP TCP 転送を介して実行されるようにするには、次の 2 つのカスタムルールを含むファイアウォール ポリシーを適用します（優先度の順に示します）。
- 選択した VM のポート 22 への
35.235.240.0/20からの上り（内向き）を許可します。35.235.240.0/20は、IAP TCP 転送で使用される IP 範囲です。 0.0.0.0/0からすべての VM のポート 22 への上り（内向き）を拒否します。