Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

セキュリティ上の考慮事項

このページでは、Google Cloud NetApp Volumes のセキュリティに関する考慮事項の概要について説明します。これらの考慮事項には、ネットワーク保護、アクセス制御、データ暗号化が含まれます。

ネットワークに関するセキュリティ上の考慮事項

Google Cloud NetApp Volumes は、次の分離されたセキュリティレイヤを備えた保護されたアーキテクチャフレームワークを提供します。

プロジェクトレベルのセキュリティ: 管理者がコンソール、Google Cloud SDK、API を使用して、ストレージプールやボリュームなどの NetApp Volumes リソースを管理するために使用する管理セキュリティレイヤ。 Google Cloud このレイヤは IAM ロールと権限によって保護されます。プロジェクトレベルのセキュリティの詳細については、 IAM 権限を設定するをご覧ください。
ネットワークレベルのセキュリティ: ネットワーク接続ストレージ（NAS）プロトコル（サーバーメッセージブロック（SMB）とネットワークファイルシステム（NFS））を使用してデータボリュームにアクセスするために使用されるネットワークレイヤ。

Virtual Private Cloud（VPC）ネットワークを介して、NAS プロトコルを使用してボリューム内のデータにアクセスできます。VPC ピアリングルーティングを VPC に置き換えるサードパーティソリューションを明示的に使用しない限り、NetApp Volumes へのすべてのデータアクセスは VPC を介してのみ可能です。

VPC 内では、ファイアウォールとプロトコル固有のアクセス制御メカニズムの設定により、アクセスをさらに制限できます。

ボリュームアクセスのファイアウォールルール

ファイアウォールルールは Google Cloud VPC を保護します。クライアントから NetApp Volumes へのアクセスを有効にするには、特定のネットワークトラフィックを許可する必要があります。

NFS、SMB、iSCSI ボリュームアクセスのファイアウォールルールの詳細については、次のセクションをご覧ください。

Active Directory アクセスのファイアウォールルール

NetApp Volumes は、Active Directory ドメインコントローラを識別するために、Active Directory ポリシーで構成された DNS サーバー上の次のポートにアクセスする必要があります。 NetApp Volumes は、Active Directory ドメインコントローラの検出に DNS ルックアップを使用します。

ICMPV4
DNS 53 TCP
DNS 53 UDP

NetApp Volumes の CIDR 範囲からのトラフィックに対して、すべての Active Directory ドメインコントローラで次のポートを開きます。

ICMPV4
LDAP 389 TCP
SMB over IP 445 TCP
Secure LDAP 636 TCP
Kerberos 464 TCP
Kerberos 464 UDP
Kerberos 88 TCP
Kerberos 88 UDP

ファイアウォールのソース範囲を指定するには、プライベートサービスアクセスの構成時に指定した完全な CIDR の範囲を使用します。詳細については、プライベートサービスアクセスを構成するをご覧ください。

ファイアウォールタグを Active Directory サーバーにアタッチする

次の手順に沿って、ファイアウォールタグを Active Directory サーバーにアタッチします。

ファイアウォールルールを Active Directory DNS サーバーにアタッチします。

gcloud compute firewall-rules create netappvolumes-to-dns \
  --allow=icmp,TCP:53,UDP:53 \
  --direction=ingress \
  --target-tags=allow-netappvolumes-to-dns \
  --source-ranges=NETAPP_VOLUMES_CIDR \
  --network=VPC_NAME

ファイアウォールルールを Active Directory ドメインコントローラにアタッチします。

gcloud compute firewall-rules create netappvolumes-to-activedirectory \
  --allow=icmp,TCP:88,UDP:88,TCP:389,TCP:445,TCP:464,UDP:464,TCP:636 \
  --direction=ingress \
  --target-tags=allow-netappvolumes-to-activedirectory \
  --source-ranges=NETAPP_VOLUMES_CIDR \
  --network=VPC_NAME

次の情報を置き換えます。

NETAPP_VOLUMES_CIDR: NetApp Volumes CIDR
VPC_NAME: VPC の名前

次のタグを DNS サーバーにアタッチします。
```
allow-netappvolumes-to-dns
```
次のタグをドメインコントローラにアタッチします。
```
allow-netappvolumes-to-activedirectory
```

NFS プロトコルのボリュームアクセス制御

NetApp Volumes は、最大 20 個のエクスポートルールを含む単一のエクスポートポリシーを使用して、NFS プロトコルによるアクセスを保護します。エクスポートルールは、ボリュームのマウント権限を持つクライアントを指定する IPv4 アドレスと IPv4 CIDR のカンマ区切りリストです。NetApp Volumes は、エクスポートルールを順番に評価し、最初の一致で停止します。最適な結果を得るには、エクスポートルールを最も具体的なものから最も一般的なものに並べることをおすすめします。エクスポートルールの詳細については、エクスポートポリシーを使用したボリュームアクセス制御をご覧ください。

SMB プロトコルのボリュームアクセス制御

SMB は共有レベルの権限を使用してボリュームアクセスを保護し、Active Directory に対する認証を必要とします。これらの権限を使用すると、ネットワーク経由で共有にアクセスできるユーザーを制御できます。

ボリュームは、[Everyone] と [Full Control] の共有レベルの権限で作成されます。共有レベルの権限は、Windows コンソールまたは Windows CLI を使用して変更できます。

Windows コンソールまたは Windows CLI を使用して SMB 共有レベルの権限を変更する手順は次のとおりです。

Windows コンソール

[Windows スタート] アイコンを右クリックし、[コンピューターの管理] を選択します。
[コンピューターの管理] コンソールが開いたら、[操作] > [別のコンピューターに接続] をクリックします。
[コンピューターの選択] ダイアログで、SMB 共有の NetBIOS 名を入力し、[OK] をクリックします。
ファイル共有に接続したら、[システムツール] > [共有フォルダ] > [共有] に移動して、共有を検索します。
[共有名] をダブルクリックし、[共有のアクセス許可] タブを選択して、共有の権限を制御します。

Windows CLI

Windows コマンドラインを開きます。

ファイル共有に接続します。

fsmgmt.msc /computer=<netbios_name_of_share>

ファイル共有に接続したら、[システムツール] > [共有フォルダ] > [共有] に移動して、共有を検索します。
[共有名] をダブルクリックし、[共有のアクセス許可] タブを選択して、共有の権限を制御します。

iSCSI プロトコルのボリュームアクセス制御

iSCSI NetApp Volumes へのアクセスは、1 つ以上の iSCSI イニシエータ IQN を含むリージョンオブジェクトであるホストグループを使用して管理されます。iSCSI イニシエータは通常、iSCSI プロトコルを使用してネットワーク経由でストレージターゲットに接続するクライアントシステムまたはサーバーです。

iSCSI ボリュームが作成されると、ホストグループにアタッチされます。この関係により、iSCSI ボリュームへのアクセス権がそのホストグループ内の iSCSI クライアント（イニシエータ）に付与され、LUN を検出してストレージリソースを使用できるようになります。ホストグループのメンバーであるイニシエータのみが、割り当てられた iSCSI ボリュームを表示して接続できます。

ホストグループと iSCSI アクセスの主な特徴は次のとおりです。

公開設定の管理: ホストグループは、特定のボリュームを表示してアクセスできる iSCSI クライアントを制限します。イニシエータがホストグループに属していない場合、LUN を検出または接続できません。
リージョンスコープ: ホストグループはリージョンオブジェクトであり、構成とメンバーシップは環境内の特定のリージョンに限定されます Google Cloud 。
クライアントサイドのセキュリティ: ホストグループはボリュームの公開設定を制御しますが、 iSCSI クライアント管理者はクライアントシステムでユーザーレベルのアクセス制御を実装する責任があります。これには、iSCSI ボリュームをマウントできるユーザーと、作成されたファイルシステムにアクセスできるユーザーの管理が含まれます。

ホストベースのファイルシステムの権限

LUN がホストにマッピングされると、ホストのオペレーティングシステムがファイルシステムの権限とアクセス制御の管理を担当します。たとえば、Windows ホストは NTFS 権限と ACL を使用しますが、Linux ホストと UNIX ホストは標準の UNIX ファイル権限を使用し、必要に応じて ACL を使用してファイルとディレクトリを保護します。

この 2 層のセキュリティアプローチにより、承認されたホストのみがブロックレベルでストレージにアクセスできるようになります。一方、ホストオペレーティングシステムは、組織のポリシーに従ってファイルレベルのセキュリティを管理します。

ファイルアクセス制御

以降のセクションでは、NetApp Volumes のファイルレベルのアクセス制御について詳しく説明します。

ボリュームセキュリティスタイル

NetApp Volumes には、Linux プラットフォームと Windows プラットフォームのさまざまな権限セットに対応するために、UNIX と NTFS の 2 つのボリュームセキュリティスタイルが用意されています。

UNIX: UNIX セキュリティスタイルで構成されたボリュームは、UNIX モードビットと NFSv4 ACL を使用してファイルアクセスを制御します。
NTFS: NTFS セキュリティスタイルで構成されたボリュームは、NTFS ACL を使用してファイルアクセスを制御します。

ボリュームのセキュリティスタイルは、ボリュームのプロトコルの選択によって異なります。

プロトコルの種類	ボリュームセキュリティスタイル
NFSv3	UNIX
NFSv4.1	UNIX
両方（NFSv3 と NFSv4.1）	UNIX
SMB	NTFS
デュアル（SMB と NFSv3）	UNIX または NTFS
デュアル（SMB と NFSv4.1）	UNIX または NTFS

デュアルプロトコルの場合、ボリュームの作成時にのみセキュリティスタイルを選択できます。

UNIX スタイルのボリュームの NFS ファイルレベルのアクセス制御

クライアントがボリュームを正常にマウントすると、NetApp Volumes はモードビットと呼ばれる標準の UNIX 権限モデルを使用して、ファイルとディレクトリのアクセス権を確認します。権限は chmod を使用して設定および変更できます。

NFSv4.1 ボリュームでは、NFSv4 アクセス制御リスト（ACL）も使用できます。ファイルまたはディレクトリにモードビットと NFSv4 ACL の両方がある場合、権限チェックには ACL が使用されます。NFSv3 と NFSv4.1 の両方のプロトコルタイプを使用するボリュームにも同じことが当てはまります。NFSv4 ACL は、nfs4_getfacl と nfs4_setfacl を使用して設定および変更できます。

新しい UNIX スタイルのボリュームを作成すると、root:root がルート i ノードの所有権を持ち、0770 権限を持ちます。この所有権と権限の設定により、root 以外のユーザーはマウント後にボリュームにアクセスしようとすると permission denied エラーが発生します。ルート以外のユーザーがボリュームにアクセスできるようにするには、ルートユーザーが chown を使用してルート inode の所有権を変更し、chmod を使用してファイル権限を変更する必要があります。

NTFS スタイルのボリュームの SMB ファイルアクセス制御

NTFS スタイルのボリュームには、NTFS 権限モデルを使用することをおすすめします。すべてのファイルとディレクトリに NTFS ACL があります。これは、エクスプローラ、icacls コマンドラインツール、PowerShell を使用して変更できます。NTFS 権限モデルでは、新しいファイルとフォルダは親フォルダから権限を継承します。

マルチプロトコルユーザーマッピング

デュアルプロトコルボリュームの場合、クライアントは NFS と SMB を使用して同じデータにアクセスできます。ボリュームは、ボリュームのセキュリティスタイルを UNIX 権限または NTFS 権限のいずれかに設定することで構成されます。

デュアルプロトコルの SMB ボリュームと NFS ボリュームを作成する場合は、Active Directory にデフォルトユーザーが含まれていることを強くおすすめします。デフォルトユーザーは、NFS クライアントが Active Directory で使用できないユーザー ID を使用して NFS 呼び出しを送信するときに使用されます。 NetApp Volumes は、デフォルトの UNIX ユーザーとして機能する pcuser というユーザーを検索しようとします。そのユーザーが見つからない場合、NFS 呼び出しへのアクセスは拒否されます。

次の属性を使用して、Active Directory にデフォルトユーザーを作成することをおすすめします。

uid = pcuser
uidnumber = 65534
cn = pcuser
gidNumber = 65534
objectClass = user

クライアントが使用するプロトコル（NFS または SMB）とボリュームのセキュリティスタイル（UNIX または NTFS）に応じて、NetApp Volumes はユーザーのアクセス権を直接確認するか、最初にユーザーを他のプラットフォームの ID にマッピングする必要があります。

アクセスプロトコル	セキュリティスタイル	プロトコルで使用される ID	必要なマッピング
NFSv3	UNIX	ユーザー ID とグループ ID	なし
NFSv3	NTFS	ユーザー ID とグループ ID	ユーザー ID からユーザー名、セキュリティ識別子へのマッピング
SMB	UNIX	セキュリティ識別子	セキュリティ識別子からユーザー名、ユーザー ID へのマッピング
SMB	NTFS	セキュリティ識別子	なし

マッピングが必要な場合、NetApp Volumes は Active Directory LDAP に保存されているデータに依存します。詳細については、Active Directory のユースケースをご覧ください。

マルチプロトコルユーザーマッピングシナリオ: UNIX ボリュームへの SMB アクセス

科学者のチャーリー E. （charliee）は、Windows クライアントから SMB を使用して NetApp Volumes ボリュームにアクセスしたいと考えています。ボリュームには Linux コンピューティングクラスタによって生成された結果が含まれているため、ボリュームは UNIX 権限を保存するように構成されています。

Windows クライアントは SMB 呼び出しをボリュームに送信します。SMB 呼び出しには、ユーザー ID がセキュリティ識別子として含まれています。セキュリティ識別子は、ユーザー ID とグループ ID のファイル権限と比較できないため、マッピングが必要です。

必要なマッピングを完了するために、NetApp Volumes は次の手順を行います。

NetApp Volumes は、Active Directory にセキュリティ識別子をユーザー名に解決するようリクエストします（例: S-1-5-21-2761044393-2226150802-3019316526-1224 から charliee）。
NetApp Volumes は、Active Directory に charliee のユーザー ID とグループ ID を返すようリクエストします。
NetApp Volumes は、返されたユーザー ID とグループ ID を使用して、ファイルの所有権ユーザー ID とグループ ID に対してアクセスを確認します。

マルチプロトコルユーザーマッピングシナリオ: NTFS ボリュームへの NFS アクセス

エンジニアのアマル L. は、Linux クライアントから NFS を使用してボリューム上のデータにアクセスする必要があります。このボリュームは主に Windows データの保存に使用されるため、NTFS セキュリティスタイルで構成されています。

Linux クライアントは NFS 呼び出しを NetApp Volumes に送信します。NFS 呼び出しには、マッピングなしではセキュリティ識別子と一致させることができないユーザー ID とグループ ID の識別子が含まれています。

必要なマッピングを完了するために、NetApp Volumes は Active Directory にユーザー ID のユーザー名をリクエストし、ユーザー名のセキュリティ識別子を返すようリクエストします。次に、返されたセキュリティ識別子を使用して、アクセスしたファイルのオーナーセキュリティ識別子に対してアクセスを確認します。

転送データの暗号化

転送データの暗号化により、ネットワーク経由でのデータの傍受を防ぐことができます。ボリュームレプリケーション、統合バックアップ、ボリューム移行のトラフィックは、デフォルトで TLS 1.2 を使用して暗号化されます。NFS トラフィックと SMB トラフィックの場合は、プロトコル固有の暗号化設定を構成して保護を強化できます。

NFS

NFS ボリュームの場合は、セキュリティを最大限に高めるために、Kerberos krb5p 暗号化を有効にした NFSv4.1 を使用します。

SMB

SMB ボリュームの場合は、セキュリティを最大限に高めるために、Active Directory ポリシーで AES 暗号化を有効にし、ボリュームで SMB 暗号化を有効にします。

ボリュームレプリケーション

NetApp Volumes は、リージョン間でボリュームを複製してデータ保護を提供できます。 Google Cloud トラフィックは Google Cloudに存在するため、 Google のネットワークインフラストラクチャは転送プロセスを保護します。このプロセスでは、不正な傍受を防ぐためにアクセスが制限されています。また、レプリケーショントラフィックは FIPS 140-2 準拠の TLS 1.2 標準を使用して暗号化されます。

統合バックアップ

統合バックアップでは、サービス内で NetApp Volumes のバックアップが作成されます。バックアップトラフィックは Google のネットワークインフラストラクチャ内に留まり、FIPS 140-2 準拠の TLS 1.2 標準を使用して暗号化されます。バックアップボルトには、デフォルトで Google-managed encryption key を使用して、または顧客管理の暗号鍵（CMEK）を使用して、これらのバックアップを保存できます。

ボリューム移行

ボリューム移行では、ソース ONTAP または Cloud Volumes ONTAP システムから NetApp Volumes にデータが送信されます。ソースシステムと NetApp Volumes 間の通信は、FIPS 140-2 準拠の TLS 1.2 標準を使用して暗号化されます。

NetApp Volumes は移行を開始し、次のプロトコルとポートを使用します。

ICMP
10000/TCP
11104/TCP
11105/TCP

ONTAP システムのクラスタ間論理インターフェース（LIF）と NetApp Volumes の移行 IP アドレスの間のファイアウォールで、これらのポートが許可されていることを確認してください。

次のステップ

サービス境界で NetApp Volumes を保護する。

セキュリティ上の考慮事項 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

ネットワークに関するセキュリティ上の考慮事項

ボリューム アクセスのファイアウォール ルール

Active Directory アクセスのファイアウォール ルール

ファイアウォール タグを Active Directory サーバーにアタッチする

NFS プロトコルのボリューム アクセス制御

SMB プロトコルのボリューム アクセス制御