このページは 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 のみ）
3260 TCP iSCSI

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

ICMPV4
DNS 53 TCP
DNS 53 UDP

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

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
```

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

iSCSI アクセスの場合、NetApp ボリュームは特定のネットワークポートを使用して、イニシエータ（クライアント）とターゲット（ストレージボリューム）間の通信を有効にします。接続を適切に行い、ブロックストレージボリュームに正常にアクセスするには、必要なポートを許可するようにファイアウォールを構成する必要があります。

iSCSI イニシエータが次の NetApp Volumes ポートと通信できることを確認します。

3260 TCP - iSCSI ターゲットポート

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 の [スタート] アイコンを右クリックし、[コンピューターの管理] を選択します。
[Computer Management] コンソールが開いたら、[Action] > [Connect to another computer] をクリックします。
[Select Computer] ダイアログで、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 を検出したり、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 の両方のプロトコルタイプを使用するボリュームについても同様です。nfs4_getfacl と nfs4_setfacl を使用して、NFSv4 ACL を設定および変更できます。

新しい UNIX スタイルのボリュームを作成すると、root:root がルート inode の所有権と 0770 権限を持ちます。この所有権と権限の設定により、マウント後に非 root ユーザーがボリュームにアクセスすると permission denied エラーが発生します。root 以外のユーザーがボリュームにアクセスできるようにするには、root ユーザーが chown を使用して root 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	セキュリティ識別子からユーザー名、ユーザー ID へのマッピング
SMB	NTFS	セキュリティ ID	なし

マッピングが必要な場合、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 にセキュリティ ID をユーザー名（S-1-5-21-2761044393-2226150802-3019316526-1224 から charliee など）に解決するよう要求します。
NetApp Volumes は、Active Directory に charliee のユーザー ID とグループ ID を返すよう要求します。
NetApp Volumes は、返されたユーザー ID とグループ ID を使用して、ファイルの所有権のユーザー ID とグループ ID に対してアクセスを確認します。

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

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

Linux クライアントが NetApp Volumes に NFS 呼び出しを送信します。NFS 呼び出しには、マッピングなしではセキュリティ ID と照合できないユーザー 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 標準を使用して暗号化されます。また、Backup Vault は、セキュリティを強化するために Google-owned and Google-managed encryption key を使用してこれらのバックアップを保存します。

ボリュームの移行

ボリュームの移行では、移行元の 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 ボリュームを保護する。

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

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

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

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

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

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

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

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

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

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

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