Google Cloud NetApp Volumeのアーキテクチャ
変更を提案
PDF
Google Cloud NetApp Volumesは、CloudSQL、Google Cloud VMware Engine（GCVE）、ファイルストアなど、Google Cloudの他のネイティブサービスと同様にサービスの提供に使用します "Google PSA"。PSAでは、サービスはサービスプロデューサープロジェクト内に構築されます。このプロジェクトは、を使用して "vPCネットワークピアリング"サービスコンシューマに接続します。サービスプロデューサーはNetAppによって提供および運用され、サービスコンシューマは顧客プロジェクトのVPCであり、Google Cloud NetApp Volumeのファイル共有にアクセスするクライアントをホストします。
次の図は、Google Cloud NetApp Volumesのドキュメントのから参照しています。この図は概要を示しています "アーキテクチャセクション"。
点線の上の部分は、ボリュームのライフサイクルを制御するサービスのコントロールプレーンを示しています。点線の下の部分は、データプレーンを示しています。左側の青いボックスはユーザVPC（サービスコンシューマ）を示し、右側の青いボックスはネットアップが提供するサービスプロデューサーです。どちらもVPCピアリングを介して接続されます。
テナンシーモデル
Google Cloud NetApp Volumeでは、個 々 のプロジェクトは固有のテナントとみなされます。つまり、ボリュームやSnapshotコピーの操作はプロジェクト単位で実行されます。つまり、すべてのボリュームは、で作成されたプロジェクトによって所有され、そのプロジェクトだけが、デフォルトでボリューム内のデータを管理およびアクセスできます。これは、サービスのコントロールプレーンビューと見なされます。
共有 VPC
データプレーンビューでは、Google Cloud NetApp Volumeを共有VPCに接続できます。ボリュームは、ホスティングプロジェクトまたは共有VPCに接続されたサービスプロジェクトのいずれかで作成できます。その共有VPCに接続されたすべてのプロジェクト（ホストまたはサービス）が、ネットワークレイヤのボリュームにアクセスできます（TCP / IP）。共有VPCでネットワーク接続を確立しているすべてのクライアントはNASプロトコルを使用してデータにアクセスできる可能性があるため、個々のボリュームでのアクセス制御（ユーザ/グループのアクセス制御リスト（ACL）やNFSエクスポートのホスト名/ IPアドレスなど）を使用して、データにアクセスできるユーザを制御する必要があります。
Google Cloud NetApp Volumeは、お客様のプロジェクトごとに最大5つのVPCに接続できます。コントロールプレーンでは、どのVPCに接続されているかに関係なく、作成されたすべてのボリュームをプロジェクトで管理できます。データプレーンではVPCが相互に分離され、各ボリュームは1つのVPCにのみ接続できます。
個々のボリュームへのアクセスは、プロトコル固有の（NFS / SMB）アクセス制御メカニズムによって制御されます。
つまり、ネットワークレイヤでは、共有VPCに接続されているすべてのプロジェクトがボリュームを表示できますが、管理側では、コントロールプレーンでしか所有者プロジェクトにボリュームを表示できません。
vPCサービスコントロール
vPCサービスコントロールは、インターネットに接続され、世界中でアクセス可能なGoogleクラウド サービス の周辺にアクセス制御境界を確立します。これらのサービスは、ユーザIDを使用してアクセス制御を提供しますが、どのネットワークロケーション要求の送信元を制限することはできません。vPCサービスコントロールは、定義されたネットワークへのアクセスを制限する機能を導入することで、このギャップを解消します。
Google Cloud NetApp Volumesデータプレーンは、外部インターネットには接続されず、ネットワーク境界（境界）が明確に定義されたプライベートVPCに接続されます。ネットワーク内では、各ボリュームはプロトコル固有のアクセス制御を使用します。外部ネットワーク接続は、Google Cloudプロジェクト管理者によって明示的に作成されます。ただし、コントロールプレーンはデータプレーンと同じ保護機能を備えておらず、有効なクレデンシャルを使用してどこからでもアクセスできます（ "JWTトークン"）。
つまり、Google Cloud NetApp Volumesデータプレーンはネットワークアクセス制御機能を提供します。VPCサービス制御をサポートする必要はなく、VPCサービス制御を明示的に使用することもありません。
パケットのスニッフィング/トレースに関する考慮事項
パケットキャプチャは、ネットワークの問題やその他の問題（NAS権限、LDAP接続など）のトラブルシューティングに役立ちますが、悪意を持ってネットワークIPアドレス、MACアドレス、ユーザ名およびグループ名、エンドポイントで使用されているセキュリティレベルなどの情報を取得することもできます。Google Cloudネットワーク、VPC、およびファイアウォールルールの設定方法が原因で、ユーザのログインクレデンシャルやを使用しないとネットワークパケットへの不要なアクセスを取得できなくなります "JWTトークン" クラウドインスタンスへ。パケットキャプチャはエンドポイント（仮想マシン（VM）など）でのみ可能であり、VPC内部のエンドポイントでのみ可能です。ただし、共有VPCまたは外部ネットワークトンネル/ IP転送を使用してエンドポイントへの外部トラフィックを明示的に許可している場合は除きます。クライアントの外部でトラフィックをスニファする方法はありません。
共有VPCを使用すると、NFS Kerberosを使用した転送中の暗号化や、"SMB暗号化"トレースから収集された情報の大部分をマスクできます。ただし、一部のトラフィックは、やなどのプレーンテキストで送信されます"DNS""LDAPクエリ"。次の図は、Google Cloud NetApp Volumeから送信されたプレーンテキストLDAPクエリからのパケットキャプチャと、公開される可能性のある識別情報を示しています。Google Cloud NetApp VolumeのLDAPクエリでは、現在、暗号化またはLDAP over SSLはサポートされていません。NetApp Volumes - Active Directoryから要求された場合、パフォーマンスでLDAP署名がサポートされます。NetApp Volumes-SWではLDAP署名がサポートされません。
|
unixUserPasswordはLDAPによって照会され、プレーンテキストではなくソルトハッシュで送信されます。デフォルトでは、Windows LDAPではunixUserPasswordフィールドは読み込まれません。このフィールドは、LDAPを使用してクライアントへの対話型ログインを行う必要がある場合にのみ必要になります。Google Cloud NetApp Volumeでは、インスタンスへの対話型LDAPログインはサポートされていません。 |
次の図は、AUTH_SYSでNFSをキャプチャしたあとの、NFS Kerberos通信からのパケットキャプチャを示しています。トレースで使用できる情報が2つの違いと、転送中の暗号化を有効にすることでNASトラフィックの全体的なセキュリティが向上することに注意してください。
VMネットワークインターフェイス
攻撃者のトリックの1つとして、のVMに新しいNIC（ネットワークインターフェイスカード）を追加する方法があります "プロミスキャスモードです" （ポートミラーリング）を使用するか、既存のNICでプロミスキャスモードを有効にして、すべてのトラフィックをスニファします。Google Cloudで新しいNICを追加するには、VMを完全にシャットダウンする必要があります。これによりアラートが生成されるため、攻撃者はこのことに気づかれません。
また、NICをプロミスキャスモードに設定することはできず、Google Cloudでアラートをトリガーします。