このページは Cloud Translation API によって翻訳されました。

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

このページでは、Google Cloud NetApp Volumes のセキュリティに関する考慮事項の概要について説明します。

ネットワーキングのセキュリティ上の考慮事項

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

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

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

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

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

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

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

NFS は、クライアントとサーバー間の通信にさまざまなポートを使用します。適切な通信とボリュームのマウントを確実に行うには、ファイアウォールでポートを有効にする必要があります。

NetApp Volumes は NFS サーバーとして機能し、NFS に必要なネットワークポートを公開します。NFS クライアントに、次の NetApp Volumes ポートとの通信権限があることを確認します。

111 TCP/UDP portmapper
635 TCP/UDP mountd
2049 TCP/UDP nfsd
4045 TCP/UDP nlockmgr（NFSv3 のみ）
4046 TCP/UDP status（NFSv3 のみ）

NetApp Volumes の IP アドレスは、ネットワークピアリング中にサービスに割り当てた CIDR 範囲から自動的に割り当てられます。詳細については、CIDR を選択するをご覧ください。

NFSv3 でのアドバイザリロックの使用

NFSv3 でアドバイザリロックを使用する場合は、クライアントで rpc.statd デーモンを実行してネットワークロックマネージャーをサポートする必要があります。これは、NFS と連携して、ネットワーク経由で System V スタイルのアドバイザリファイルとレコードのロックを提供します。NFS クライアントは、rpc.statd がネットワークロックマネージャーのコールバックを受信できるように、上り（内向き）ポートを開く必要があります。ほとんどの Linux ディストリビューションでは、最初の NFS 共有をマウントすると rpc.statd が開始されます。ランダムなポートを使用します。このポートは rpcinfo -p コマンドを使用して確認できます。rpc.statd をファイアウォール対応にするには、静的ポートを使用するように構成します。

rpc.statd の静的ポートを設定するには、次のリソースをご覧ください。

NFSv3 アドバイザリロックまたはネットワークロックマネージャーを使用しない場合は、nolock マウントオプションを使用して NFSv3 共有をマウントすることをおすすめします。

NFSv4.1 は、NFSv4.1 プロトコル自体にロック関数を実装します。この関数は、ポート 2049 の NFSv4.1 サーバーへのクライアント開始の TCP 接続を介して実行されます。クライアントは上り（内向き）トラフィック用のファイアウォールポートを開く必要はありません。

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

SMB は、クライアントとサーバー間の通信にさまざまなポートを使用します。適切な通信を確保するには、ファイアウォールでポートを有効にする必要があります。

NetApp Volume は SMB サーバーとして機能し、SMB に必要なネットワークポートを公開します。SMB クライアントが次の NetApp Volumes ポートとの通信を許可されていることを確認します。

445 TCP SMB2/3
135 TCP msrpc と 40001 TCP SMB CA: SMB 3.x の継続的に利用可能な共有にのみ使用されます。これらのポートは、連続的に利用できない共有には必要ありません。

このサービスはポート 139/TCP を公開しますが、使用しません。

SMB を機能させるために、SMB クライアントが上り（内向き）ポートを公開する必要はありません。

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

NetApp Volumes は、Active Directory ポリシーで構成された DNS サーバーの次のポートにアクセスして、Active Directory ドメインコントローラを識別する必要があります。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

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 はエクスポートルールを順番に評価し、最初の一致後に停止します。最適な結果を得るには、エクスポートルールを最も具体的なものから最も一般的な順に並べ替えることをおすすめします。

NFS バージョンに基づいてポリシーを確認するには、次のタブを使用します。

Kerberos を使用しない NFS

Kerberos のないすべての NFS バージョンでは、AUTH_SYS セキュリティフレーバーが使用されます。このモードでは、信頼できるクライアントのみがユーザー ID とグループ ID の整合性を確保できるように、エクスポートルールを厳密に管理する必要があります。

セキュリティ対策として、NFS サーバーは UID=0（root）を使用して NFS 呼び出しを UID=65535（匿名）に自動的にマッピングします。これは、ファイルシステムに対する権限が制限されています。ボリュームの作成時に、root アクセスオプションを有効にしてこの動作を制御できます。ルートアクセスを有効にすると、ユーザー ID 0 は 0 のままになります。ベストプラクティスとして、既知の管理者ホストの root アクセスを有効にし、他のすべてのクライアントの root アクセスを無効にする専用の書き出しルールを作成します。

Kerberos を使用した NFSv4.1

Kerberos を使用した NFSv4.1 は、エクスポートポリシーと Kerberos を使用した追加の認証を使用してボリュームにアクセスします。エクスポートルールを構成して、以下に適用できます。

Kerberos のみ（krb5）
Kerberos 署名（krb5i）
Kerberos プライバシー（krb5p）

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

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

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

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

Windows コンソール

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

Windows CLI

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

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

fsmgmt.msc /computer=<netbios_name_of_share>

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

ファイルアクセス制御

以降のセクションでは、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 にはルート inode の所有権と 0770 権限が付与されます。この所有権と権限の設定により、root 以外のユーザーは、マウント後にボリュームにアクセスするときに permission denied エラーを受け取ります。root 以外のユーザーがボリュームにアクセスできるようにするには、root ユーザーが chown を使用して root inode の所有権を変更し、chmod を使用してファイル権限を変更する必要があります。

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

NTFS 形式のボリュームには、NTFS 権限モデルを使用することをおすすめします。すべてのファイルとディレクトリには NTFS ACL があり、File Explorer、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	セキュリティ識別子からユーザー名、ユーザー ID
SMB	NTFS	セキュリティ ID	なし

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

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

科学者 Charlie 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 は、charliee のユーザー ID とグループ ID を返すよう Active Directory にリクエストします。
NetApp Volumes は、返されたユーザー ID とグループ ID を使用して、ファイルの所有権のユーザー ID とグループ ID に対するアクセスを確認します。

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

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

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

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

転送データの暗号化

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 Volume のバックアップが作成されます。バックアップトラフィックは、FIPS 140-2 に準拠した TLS 1.2 標準暗号化を使用して、Google の安全なネットワークインフラストラクチャ内に留まります。また、Backup Vault は、セキュリティを強化するために Google-owned and Google-managed encryption key を使用してこれらのバックアップを保存します。

次のステップ

サービス境界を使用して NetApp ボリュームを保護する。

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

ネットワーキングのセキュリティ上の考慮事項

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

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

NFSv3 でのアドバイザリ ロックの使用

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

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

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

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