Compute Enclaveのセキュリティ機能

アイデンティティ・プロバイダのセキュリティ機能

企業では、ユーザーのログイン/パスワードを管理し、セキュアなwebサイト、サービスおよびリソースにアクセスするユーザーを認証するために、アイデンティティ・プロバイダ(IdP)が一般的に使用されています。テナンシ管理者は、従業員がOracle Private Cloud Appliance 「コンピュートWeb UI」で既存のログインとパスワードを使用できるように、サポートされているIdPとフェデレートできます。

Oracle Private Cloud Applianceは、次のSecurity Assertion Markup Language (SAML) 2.0準拠のアイデンティティ・プロバイダをサポートしています:

Microsoft Active Directory Federation Servicesを介したActive Directory

Oracle Private Cloud Applianceでのアイデンティティ・プロバイダの使用には、次の条件が適用されます:

ユーザーは「コンピュートWeb UI」にのみアクセスできます - フェデレーテッド・ユーザーは、Oracle Private Cloud Appliance Identity and Access Management (IAM)フレームワーク内で管理されません。そのため、OCI CLIの使用またはプリファレンスの管理のためにAPIキーを追加することはできません。
フェデレーテッド・ユーザーが「コンピュートWeb UI」内で操作を実行する権限を持っているには、指定されたActive DirectoryグループからOracle Private Cloud Applianceへのグループ・マッピングを行う必要があります。
Oracle Private Cloud Appliance 「コンピュートWeb UI」に対する多要素認証は、アイデンティティ・プロバイダを介してのみ使用できます。

アイデンティティ・プロバイダが自己署名証明書を使用する場合、IdPを追加する前に、認証局(CA)の信頼情報をOracle Private Cloud Applianceに追加するための追加のステップを実行する必要があります。 CA情報を追加するには、アプライアンス管理者が次を行う必要があります:

管理ノードのrootアカウントを使用して、Oracle Private Cloud Applianceの管理ノードにアクセスします。
管理ノードに含まれるツールを使用して、CA X.509証明書を管理ノードに配布します。

詳細は、「Oracle Private Cloud Appliance管理者ガイド」の「アイデンティティ・プロバイダの自己署名証明書の検証」の項を参照してください

Oracleは、テナンシのアイデンティティ・プロバイダに関する次の推奨事項を作成します:

サポートされているアイデンティティ・プロバイダが使用可能な場合は、フェデレーションを使用して「コンピュートWeb UI」への認証を管理します。
フェデレーテッドIdP管理者グループにマップされるコンピュート・テナンシ内に管理者グループを作成し、フェデレーテッド・ユーザーがIdP管理者グループに割り当てられていることを確認します。
次のような緊急の目的で、ローカル(非フェデレーテッド)テナンシ管理者のみを使用してください:
- ローカル(非フェデレーテッド)管理パスワードを非常に複雑なパスワードに変更します。
- ローカル(非フェデレーテッド)パスワードを安全なロケーションにエスクロします。
- フェデレーテッドIdP管理者グループがローカル管理者およびローカル管理者グループを変更しないようにします。
- ローカル管理者アカウントの不正使用について監査ログを定期的にモニターし、不正なアクションの試行がないか確認します。
- ローカルで定義した管理者パスワードをローテーションし、定期的に、または使用直後に再エスクロすることを検討してください。

アイデンティティ・プロバイダのサポートの概要は、「Oracle Private Cloud Appliance概要ガイド」の「Identity and Access Management概要」の章を参照してください。

Microsoft Active Directoryを使用したテナンシのフェデレートの概要は、「Oracle Private Cloud Applianceユーザーズ・ガイド」の「Microsoft Active Directoryのフェデレート」に関する項を参照してください。

IAMセキュリティ機能

Oracle Private Cloud Appliance Identity and Access Management (IAM)は、ローカル・ユーザーの認証とリソースへの認可を提供します。 IAMは、次のようなセキュリティ管理を支援する組織の原則を容易にします:

パーティション - テナンシ管理者から権限を付与されたグループからアクセスできる関連リソース(クラウド・ネットワーク、コンピュート・インスタンス、ブロック・ボリュームなど)のコレクション。
グループ - 承認に関する同様の要件を持つユーザーの集合(ユーザーは複数のグループに含めることができます)。
リソース - 様々なOracle Cloud Infrastructureサービスを使用して作成されたオブジェクト(コンピュート・インスタンス、ブロック・ボリューム、ユーザーなど)。
タグ - リソースに追加されるキーおよび値の形式のMetadata
テナンシ - 追加のコンパートメントを含む、すべてのリソースを保持するルート・コンパートメント。

セキュリティ・ポリシーは、タグに関する情報をさらに絞り込むことができる、指定された集計レベル(テナンシ、コンパートメントまたはサービス)のリソースに対してIAMで定義されたアクセスのタイプを指定します。

一般的なポリシーの詳細は、「Oracle Private Cloud Applianceユーザー・ガイド」のIdentity and Access Management章の「ポリシーの管理」の項を参照してください。

テナンシ管理者の最終目標は、最小権限の原則を達成することです:

ユーザーがロールに必要なリソースおよび権限を使用してロールを達成できるようにします。
ユーザーがリソースにアクセスしたり、ロールに必要な権限のないリソースにアクセスすることを禁止します。
ユーザーまたはユーザー・グループへのリソースおよび権限の追加および削除を容易にします。

最小権限の原則を実現するには、テナンシの使用による組織概念とセキュリティ・ポリシー管理手法の組合せを使用します。

テナンシを設計および保守する場合:

ルート・コンパートメント(テナンシ)は、テナンシ全体の管理者に一元的な制御と可視性を提供するだけでなく、テナンシをチームのニーズに合わせて分割することもできます。
コンパートメントは、アクセス権限に基づいてテナンシ・リソースをグループ化し、ユーザーのグループが必要に応じてコンパートメントにアクセスすることを認可する効果的なメカニズムを提供します。たとえば、ビジネス・ユニットに属するすべてのリソースを含めるようにコンパートメントを作成し、ビジネス・ユニットのメンバーのみがコンパートメントにアクセスすることを認可できます。同様に、コンパートメントへのグループ・アクセスは、不要になった場合に迅速に取り消すことができます。
コンパートメントおよびリソース割当てについては、次の点に注意してください:
- すべてのリソースはコンパートメントに属します。
- リソースは、作成後に別のコンパートメントに再割当てできます。
- コンパートメントは作成後に削除できます。
リソース・タグは、複数のコンパートメントに分散されたリソースを論理的に集約する方法を提供します。たとえば、テナンシ・リソースの使用に応じて、testまたはproductionとしてタグ付けできます。

リソース・タグ(フリー・フォームおよび定義済タグ)の詳細は、Identity and Access Managementの章の「コンパートメントの作成と管理」の項および「Oracle Private Cloud Applianceユーザー・ガイド」の「リソース・タグ管理」の章を参照してください。

テナンシのユーザーを管理する場合:

リソースへのアクセス権を必要とする顧客組織内のすべてのユーザーに対してIAMユーザーを作成します。ユーザー・アカウント(特に管理アカウントを持つユーザー・アカウント)を共有しないでください。個別のユーザーを使用すると、各ユーザーに対する最小限のアクセス権の適用が容易になり、取得は監査ログでのアクションの追跡に役立ちます。
推奨される管理単位はIAMグループであるため、(個々のユーザーではなく)セキュリティ権限の管理と追跡が容易になります。一般に必要なタスク(ネットワーク管理、ボリューム管理など)を実行する権限を持つグループを作成し、必要に応じてこれらのグループにユーザーを割り当てます。 IAM権限を使用すると、テナンシ内の複数のコンパートメントにわたるリソースへのアクセス権をグループに付与できます。
IAMグループ内のIAMユーザーのメンバーシップを定期的に確認し、アクセス権が必要ないユーザーはグループから削除します。グループ・メンバーシップを使用したユーザー・アクセスの管理は、ユーザー数が増加しても適切にスケーリングされます。
テナンシ・リソースへのアクセスが不要なIAMユーザーを非アクティブ化します。 IAMユーザーを削除すると、そのユーザーは完全に削除されます。次のようにして、IAMユーザーを一時的に非アクティブ化できます:
- ユーザー・パスワードをローテーションし、破棄します。
- すべてのグループからメンバーシップを削除して、ユーザーのすべてのテナンシ権限を削除します。

テナンシ・ユーザーの管理に関する前述のガイダンスは、IdP統合によってわずかに変更されます。次のような留意点があります。:

ユーザーに対してグループを直接追加および削除するためのIdP管理者との連携が必要です。
グループ管理ルールは引き続き適用されます。

IAM管理のOCI CLIの使用方法の詳細は、「Oracle Private Cloud Applianceユーザー・ガイド」のIdentity and Access Managementの章を参照してください。

最小権限のサービス・レベル管理者の作成

最小特権のセキュリティ原則を実装するには、ユーザーを1つ以上のサービス管理者ロールに追加して、個々のサービスを管理するためのグループを作成できます。たとえば、ネットワーク管理者は、VCNリソースへの管理アクセス(manage)のみを必要とし、他のリソースに対するアクセスは不要です。コンピュート管理者はコンピュート権限が必要な場合がありますが、その作業にはストレージとボリュームも含まれることが多く、追加の管理権限が必要です。次の例は、管理をより詳細な範囲に分割し、管理者がサービスレベルの承認を割り当てて割り当て解除できるポリシーを示しています。

まず、一連のグループはCLIコマンドを使用して作成されます(同じアクションをGUIで実行できます):

oci iam group create --name TenancyAdmin --description "Tenancy administrators"
oci iam group create --name VolumeAdmin --description "Volume admins includes block volumes)"
oci iam group create --name NetworkAdmin --description "Network admins (VCNs, subnets, etc...)"
oci iam group create --name StorageAdmin --description "Storage administrators (Object storage)"
oci iam group create --name InstanceAdmin --description "Instance admins (compute instances, etc.)"

これらのグループには作成中のユーザーがいません。現時点では、グループに関連付けられたセキュリティ・ポリシーもありません。

次に、様々なグループがサービスを管理できるようにする一連のポリシーが作成されます:

oci iam policy create --name ServiceAdministratorPolicies --description "Policies for svc admin" 
  --statements '["Allow group TenancyAdmin to manage all-resources in tenancy", 
  "Allow group VolumeAdmin to manage volume-family in tenancy", 
  "Allow group NetworkAdmin to manage virtual-network-family in tenancy", 
  "Allow group StorageAdmin to manage object-family in tenancy", 
  "Allow group InstanceAdmin to manage instance-family in tenancy"]'

これらのグループおよびポリシーが適用されると、ローカル・ユーザーは、テナンシ全体のサービス・レベルの管理職務を迅速かつ効率的に追加および削除できます:

oci iam group add-user --group-id ocid1.group.<id> --user-id ocid1.user.<id>
oci iam group remove-user --group-id ocid1.group.<id> --user-id ocid1.user.<id>

テナンシをコンパートメントに分割して、複数のプロジェクト、環境またはその他の組織構造をサポートします。サービス・レベル管理グループを作成するガイダンスは、サービス・レベル管理グループ「コンパートメント用」の作成にすばやく適応できます。

たとえば、Human Resourcesクラウドをサポートする"HR"という名前のコンパートメントがある場合は、HRNetworkAdminなどのグループ名を選択します。

次に、ポリシー・ステートメントを、テナンシではなくHRコンパートメントを使用するように適切に適応します:

"Allow group HRNetworkAdmin to manage virtual-network-family in compartment HR"

セキュリティ監査者の作成

すべてのタスクでリソースのアクティブな管理が必要なわけではありません。コンプライアンス監査者には、クラウド・リソースの調査とリソースへのアクセスの評価のタスクが伴います。次のポリシーにより、グループInternalAuditorsのユーザーはテナンシ内のすべてのリソースを検査(list)できます:

"Allow group InternalAuditors to inspect all-resources in tenancy"

あるいは、監査者が実行する特定のロールを持っている場合があります。次のポリシー・ステートメントでは、グループUserAuditorsのユーザーがユーザーおよびグループのみを検査できます。

"Allow group UserAuditors to inspect users in tenancy"
"Allow group UserAuditors to inspect groups in tenancy"

テナンシ内のVCNファイアウォールのみを調査できる監査者グループを作成する場合は、次のポリシーを使用します:

"Allow group FirewallAuditors to inspect security-lists in tenancy"

ポリシーにcompartment <name> (<name>はコンパートメント名)を指定することで、これらすべてのポリシー例のポリシーをコンパートメントに制限できます。

テナンシ管理者グループ・メンバーシップを変更する機能の制限

グループAdministratorsのメンバーは、テナンシ内のすべてのリソースを管理できます。 Administratorsグループのメンバーシップは、グループ内のユーザーによって制御されます。通常、テナンシでユーザーを作成して追加するグループがあると便利ですが、Administratorsグループ・メンバーシップを変更しないように制限できます。次の例では、これを行うグループUserAdminsを作成します。

"Allow group UserAdmins to inspect users in tenancy"
"Allow group UserAdmins to inspect groups in tenancy"

"Allow group UserAdmins to use users in tenancy where target.group.name!='Administrators'"
"Allow group UserAdmins to use groups in tenancy where target.group.name!='Administrators'"

3番目と4番目のポリシー・ステートメントにより、UserAdminsはAPI (UpdateUser、UpdateGroup)を使用して、Administratorsグループを除くテナンシ内のすべてのグループにユーザーおよびグループを追加できます。ただし、target.group.name!='Administratorsはlistおよびget API (ListUsers, GetUser, ListGroupsおよびGetGroup)に関連していないため、これらのAPIは他のコマンドなしで失敗します。そのため、UserAdminsがユーザーおよびグループのメンバーシップ情報を取得できるようにするには、1番目と2番目のポリシー・ステートメントにinspectを明示的に追加する必要があります。

セキュリティ・ポリシーの削除または更新の防止

次の例では、テナンシ管理者が作成したセキュリティ・ポリシーを作成および更新できないようにグループPolicyAdminsを作成します:

"Allow group PolicyAdmins to use policies in tenancy" 
"Allow group PolicyAdmins to manage policies in tenancy where request.permission='POLICY_CREATE'"

2番目のセキュリティ・ポリシー・ステートメントでは、POLICY_CREATE権限は明示的に許可されますが、POLICY_DELETEおよびPOLICY_UPDATEは許可されません。

管理者によるユーザー資格証明へのアクセスまたは変更の防止

コンプライアンス要件によっては、職務の分離(特にユーザー資格証明の管理機能とテナンシ管理の分離)が必要です。この場合、TenancyAdminsとCredentialAdminsの2つの管理グループを作成できます。

TenancyAdminsは、ユーザー資格証明管理を除くすべてのテナンシ管理機能を実行でき、CredentialAdminsはユーザー資格証明を管理できます。

TenancyAdminsは、ユーザー資格証明をリスト、更新または削除するAPIを除くすべてのAPIにアクセスできます。 CredentialAdminsは、ユーザー資格証明のみを管理できます。

これらの管理グループを設定するには、次を使用します:

"Allow group TenancyAdmins to manage all resources in tenancy
 where all {request.operation!='ListApiKeys',
            request.operation!='ListAuthTokens',
            request.operation!='ListCustomerSecretKeys',
            request.operation!='UploadApiKey',
            request.operation!='DeleteApiKey',
            request.operation!='UpdateAuthToken',
            request.operation!='CreateAuthToken',
            request.operation!='DeleteAuthToken',
            request.operation!='CreateSecretKey',
            request.operation!='UpdateCustomerSecretKey',
            request.operation!='DeleteCustomerSecretKey'}"
"Allow group CredentialAdmins to manage users in tenancy
 where any {request.operation='ListApiKeys',
            request.operation='ListAuthTokens',
            request.operation='ListCustomerSecretKeys',
            request.operation='UploadApiKey',
            request.operation='DeleteApiKey',
            request.operation='UpdateAuthToken',
            request.operation='CreateAuthToken',
            request.operation='DeleteAuthToken',
            request.operation='CreateSecretKey',
            request.operation='UpdateCustomerSecretKey',
            request.operation='DeleteCustomerSecretKey'}"

ファイル・ストレージ・サービスのセキュリティ機能

Oracle Private Cloud Appliance File Storage Serviceは、耐久性が高くスケーラブルでセキュアなエンタープライズ・グレードのネットワーク・ファイル・システムを提供します。このサービスを使用すると、適切な認可を持つユーザーは、仮想クラウド・ネットワーク (VCN)内のコンピュート・インスタンスからアクセスできるファイル・システムを作成および管理できます。

ファイル・ストレージ・サービス:

NFSv3、v4、v4.1およびSMBをサポート
Advanced Encryption Standard (AES) 128ビット・アルゴリズムを使用して、ディスク上のデータを暗号化します。
ファイル・システムの定期的なスナップショットを作成できます(「Oracle Private Cloud Applianceユーザーズ・ガイド」の「スナップショットの管理」の項を参照)。
クライアント・アクセスおよび使用を管理するための様々なNFSエクスポート・オプションをサポートします。
VCNおよびネットワーク・セキュリティ・グループを使用して、共有へのクライアント・アクセスを管理します。

管理者は、次のようなセキュリティ・ポリシーで認可されているかぎり、File Storage Serviceを使用できます:

リソース・タイプ・ファミリ: file-family
リソース・タイプ: file-systems, mount-targets, export-sets

グループFileAdminが存在する場合、ファイル・ストレージ・サービスのすべての側面を管理するための許可を付与するポリシーは:

"Allow group FileAdmin to manage file-family in tenancy"

データ・ストレージは任意のシステムの重要な機能であるため、ファイル・システムを作成できるが、誤ってファイル・システムを削除できないユーザー用に2番目のグループを作成することが役立つ場合があります。たとえば、グループFileUsersがある場合、アクセスを制限するために次のポリシー・ステートメントを追加できます:

"Allow group FileUsers to manage file-systems in tenancy 
       where request.permission!='FILE_SYSTEM_DELETE'" 
"Allow group FileUsers to manage mount-targets in tenancy 
       where request.permission!='MOUNT_TARGET_DELETE'" 
"Allow group FileUsers to manage export-sets in tenancy 
       where request.permission!='EXPORT_SET_DELETE'"

ファイル・ストレージ・サービスへのアクセスを管理する方法の詳細は、「Oracle Private Cloud Applianceユーザー・ガイド」のIdentity and Access Management章の「ポリシーの管理」の項を参照してください。

クライアントからのアクセスを制限する方法やアクセスを許可する方法など、ファイルシステムへのアクセスを管理する方法については、「Oracle Private Cloud Applianceユーザーズ・ガイド」の「ファイル・システム・ストレージ」章にあるセクション「ファイル・ストレージへのアクセスの制御」を参照してください。

オブジェクト・ストアのセキュリティ機能

Oracle Private Cloud Appliance Object Storageサービスは、任意のコンテンツ・タイプの大量の非構造化データを格納し、アクセスを提供します。オブジェクト・ストレージに格納されたコンテンツは、コンピュート・インスタンスによって、またデータ・センターからOracle Private Cloud Applianceのドメインを通じて、「コンピュート・エンクレーブ」内からアクセスできます。

「オブジェクト・ストレージ」サービス:

Advanced Encryption Standard (AES) 128ビット・アルゴリズムを使用して、ディスク上の(保存されている)データを暗号化します。暗号化は既定でオンになっているため、オフにできません。暗号化キー自体は、マスター暗号化キーを使用して暗号化されます。
顧客クライアント(SDKやCLIなど)と「オブジェクト・ストレージ」パブリック・エンドポイント間で転送中のデータは、デフォルトでTLS 1.2で暗号化されます。
アップロードされた各オブジェクトに対して生成されたチェックサム、およびマルチパート・アップロードの場合は各パートに対してチェックサムによってデータの整合性が向上します。
オブジェクトには、様々な認可レベルで構築された、取消し可能な事前認証済リクエストを含めることができます。
オブジェクト・バージョニングでは、オブジェクトに対する変更を保持できます。
Write-once Read-many (WORM)保持ルールを設定して、オブジェクトが元の内容を保持するようにできます。
Oracle Private Cloud Applianceに対して認証されるユーザーは、セキュリティ・ポリシー・フレームワーク内で管理される「オブジェクト・ストレージ」サービスおよびリソースを管理できます。

前述の機能の使用の詳細は、「Oracle Private Cloud Applianceユーザーズ・ガイド」の「オブジェクト・ストレージ」の項を参照してください

セキュリティの推奨事項

IAMユーザーおよびグループの最小特権アクセスをobject-familyのリソース・タイプ(オブジェクト・ストレージ・ネームスペース、バケット、オブジェクトなど)に割り当てます。たとえば、inspect動詞では最小限の権限が付与されます。 inspect動詞では、バケットが存在するかどうかを確認し(HeadBucket)、コンパートメント内のバケットをリストできます(ListBucket)。 manage動詞は、リソースに対するすべての権限を付与します。 IAMセキュリティ・ポリシーを作成して、様々なIAMグループに適切なバケットおよびオブジェクト・アクセス権を付与できます。

オブジェクト・ストレージのバケットおよびオブジェクトのIAM動詞と権限の詳細は、「オブジェクト・ストレージ、アーカイブ・ストレージおよびデータ転送の詳細」を参照してください。

IAM資格証明がないユーザーの場合は、事前認証済リクエスト(PAR)を使用して、オブジェクトまたはバケットに期限付きアクセスを提供することをお薦めします。

事前認証済リクエスト

事前認証済リクエストは、クライアントまたはユーザーがOracle Private Cloud Applianceにログインする必要なく、オブジェクトおよびバケットへのアクセス権を付与するメカニズムを提供します。その結果、Oracle Private Cloud ApplianceにIAMユーザーが定義されていなくても、オブジェクトおよびバケットを使用できます。

オブジェクトにアクセスするための適切な権限を持つIAMユーザーは、オブジェクトへの期限付きアクセスを付与するURLを作成します。これらの権限の詳細は、「事前認証済リクエストの使用」のOracle Cloud Infrastructure情報を参照してください。次のような留意点があります。:

事前認証済リクエストの作成者は、PAR_MANAGE権限と、付与するアクセス・タイプに対する適切なIAM権限を持っている必要があります。次のいずれかへの読取り、書込みまたは読取り/書込みアクセス権を付与する事前認証済リクエストを作成できます:
- バケット内のすべてのオブジェクト
- バケット内の特定のオブジェクト。
- 指定されたプレフィクスを持つバケット内のすべてのオブジェクト。
複数のオブジェクトに適用されるリクエストの場合、ユーザーがそれらのオブジェクトをリストできるようにするかどうかを決定することもできます。
バケットへの事前認証済リクエスト・アクセスは、監査ログに記録されます。オブジェクトへの事前認証済リクエスト・アクセスは、サービス・ログに記録されます。

重要:

事前認証済リクエストの作成時にシステムによって提供される一意のURLは、ユーザーがリクエスト・ターゲットにアクセスできる唯一の方法です。 URLを永続ストレージにコピーします。 URLは作成時にのみ表示され、オブジェクト・ストレージには格納されず、後で取得することはできません。

データの耐久性と整合性

Object Storageサービスは、格納されたデータの一貫性とそのままの状態を維持するための様々な方法を提供します。次のような留意点があります。:

認可されたユーザーまたは悪意のある削除による意図しない削除を防止することで、データ損失を最小限に抑えることができます:
- 「オブジェクト・バージョニング」を使用して、新しいオブジェクトがアップロードされるか、既存のオブジェクトが上書きされるか、オブジェクトが削除されるたびに、オブジェクト・バージョンを自動的に作成します。
- BUCKET_DELETEおよびOBJECT_DELETE権限を、IAMユーザーおよびグループの最小セットに付与します。テナンシ管理者およびコンパートメント管理者にのみ削除権限を付与します。
Write once read many (WORM)コンプライアンスでは、オブジェクトを削除または変更できない必要があります。 WORMコンプライアンスを達成するには、「保持ルール」を使用します。保持ルールはバケット・レベルで構成され、バケット内のすべての個別オブジェクトに適用されます。保存ルールが削除されるか(無限ルール)、指定した期間(期限付きルール)まで、オブジェクトまたはオブジェクト・メタデータを更新、上書きまたは削除できません。

レコードの管理および保持に関する規制要件を満たすオブジェクト・ストレージ保持ルール機能機能の独立した評価については、Cohasset Associate 「SEC 17a-4(f)、FINRA 4511(c)、CFTC 1.31 (c)-(d)、およびMiFID IIコンプライアンス評価」を参照してください。
オブジェクトは、SHA-256チェックサムを使用してZFSファイル・システムに格納されるため、ファントムが読み取られず、デバイスから返された無効なデータが検出されます。

Object Storageは、耐久性のために用意されている機能に加えて、データの整合性を保証するメカニズムも提供しています:

Object Storageにアップロードされたすべてのオブジェクトに対してチェックサムが提供されます。チェックサムは次の2つの方法で使用できます:
- 格納されているオブジェクトがアップロードされたオブジェクトであることを確認するには
- 取得されたオブジェクトが最初に格納されたオブジェクトであることを確認するため
マルチパート・アップロードは、大規模なオブジェクト・アップロードの効率と回復性を目的としてObject Storageサービスによって使用されます。マルチパート・アップロードでは、MiBでパート・サイズを指定することで、ラージ・オブジェクトが小さいパートに分割されます。各パートは個別にアップロードされます。その後、Object Storageがすべてのパートを結合し、元のオブジェクトを再作成します。いずれかの部品のアップロードが失敗した場合は、オブジェクト全体ではなく、失敗した部品のみをアップロードのために再試行する必要があります。マルチパート・アップロードでは、アップロードの各パートのチェックサム値が計算され、1つのチェックサムが個々のチェックサム値のすべてにわたって計算され、オブジェクトのアップロードによってレポートされたチェックサム値が取得されます。マルチパート・アップロードで返される値を検証するには、オフライン・チェックサム計算と同じプロセスに従います。

オブジェクトが格納されたときに返されるチェックサムを使用して、オブジェクトのコンテンツが再度ダウンロードされたとき、または元のオブジェクトに対して検証され、アップロードされたオブジェクトの正確性が検証されます。

オペレーティング・システムには、チェックサム検証のための様々なツールがあります。オブジェクトのアップロード(またはバケット内のオブジェクトの表示)によって返されるチェックサムは、Base-64でエンコードされた値です。チェックサム比較に使用されるツールによっては、この値を16進数に変換する必要がある場合があります。

ネットワーキングのセキュリティ機能

VCN機能	証券摘要
パブリック・サブネットとプライベート・サブネット	VCNはサブネットにパーティション化できます。サブネットは可用性ドメインに固有です。プライベート・サブネット内のインスタンスは、パブリックIPアドレスを持つことはできません。パブリック・サブネット内のインスタンスは、必要に応じてパブリックIPアドレスを持つことができます。
セキュリティ・ルール	セキュリティ・ルールは、インスタンスへのネットワーク・アクセスを制御するステートフルおよびステートレス・ファイアウォール機能を提供します。 VCNにセキュリティ・ルールを実装するには、「ネットワーク・セキュリティ・グループ(NSG)」または「セキュリティ・リスト」を使用できます。詳細は、「セキュリティ・リストとネットワーク・セキュリティ・グループの比較」を参照してください。
ゲートウェイ	ゲートウェイによって、VCN内のリソースがVCN外の宛先と通信できるようになります。次のゲートウェイがあります: インターネット・ゲートウェイ: インターネット接続用(パブリック・サブネット内のパブリックIPアドレスを持つリソース用)。 NATゲートウェイ: 受信インターネット接続にリソースを公開しないインターネット接続の場合(プライベート・サブネットのリソースの場合)。動的ルーティング・ゲートウェイ(DRG): データ・センター・ネットワークへの接続用。サービス・ゲートウェイ: Object StorageなどのOracleサービスへのプライベート接続の場合。ローカル・ピアリング・ゲートウェイ(LPG): 同じリージョン内のピアリングされたVCNへの接続用。
ルート表ルール	ルート表は、VCNサブネットからVCN外の宛先へのトラフィックのルーティング方法を制御します。ルーティング・ターゲットは、VCNゲートウェイまたはVCN内のプライベートIPアドレスになります。
virtual-network-familyのIAMポリシー	IAMポリシーは、IAMグループによって許可される、VCN内のリソースへのアクセスおよびアクションを指定します。たとえば、IAMポリシーでは、VCNを管理するネットワーク管理者に管理権限を付与し、通常のユーザーにスコープ・ダウン権限を付与できます。

Oracleでは、Oracle Cloud Infrastructure監査ログを定期的に監視して、VCNネットワーク・セキュリティ・グループ、セキュリティ・リスト、ルート表ルールおよびVCNゲートウェイの変更を確認することをお薦めします。

ネットワーク・セグメンテーション: VCNサブネット

VCN内の複数のサブネットを使用したコンピュート・インスタンスのデプロイは、データ・センター・ネットワークへのアクセスを制御するための一般的な戦略です。これを行うには:

ネットワーク・アクセスを制御するために、VCNの階層化サブネット戦略を形成します。一般的な設計パターンでは、次のサブネット階層が使用されます:
1. 「パブリック・サブネット」: NATインスタンス、侵入検出(IDS)インスタンス、webアプリケーション・サーバーなどの外部からアクセス可能なホスト
2. データベースなどの内部ホストの場合は「プライベート・サブネット」
様々なサブネットのインスタンスが通信するために特別なルーティングは必要ありません。ただし、VCNネットワーク・セキュリティ・グループまたはセキュリティ・リストを使用して、異なる層間のトラフィックのタイプを制御できます。
プライベート・サブネット内のインスタンスにはプライベートIPアドレスのみがあり、VCN内の他のインスタンスからのみアクセスできます。 Oracleでは、セキュリティの影響を受けやすいホスト(DBシステムなど)をプライベート・サブネットに配置し、セキュリティ・ルールを使用してパブリック・サブネット内のホストへの接続のタイプを制御することをお薦めします。 VCNセキュリティ・ルールに加えて、多層防御メカニズムとして、ネットワーク・アクセス制御のためのiptablesやfirewalldなどのホスト・ベースのファイアウォールを構成します。
サービス・ゲートウェイをVCNに追加すると、トラフィックがデータ・センター・ネットワークを通過せずに、プライベート・サブネットのDBシステムをObject Storageに直接バックアップできるようになります。そのようなトラフィックを有効にするには、ルーティング・ルールおよびセキュリティ・ルールを設定する必要があります。ベア・メタルまたは仮想マシンDBシステムの詳細は、Oracle Cloud Infrastructureドキュメントの「VCNおよびサブネット」を参照してください。 Oracle Exadata DBシステムの詳細は、「Exascaleインフラストラクチャ・インスタンス上のOracle Exadataデータベース・サービスのネットワーク設定」を参照してください。

VCNセキュリティ・ルールおよびセキュリティ・リスト

VCNセキュリティには、セキュリティ・リストまたはネットワーク・セキュリティ・グループ(NSG)に収集されたルールの作成および使用が含まれます。ルールは、ステートフルまたはステートレスです。ステートフル・ルールは、インスタンスの相互作用に関する様々なことを想定します。たとえば、インスタンスに対するリクエストに適用されるステートフル・ルールは、レスポンスがあることを想定し、このレスポンスを自動的に許可します。一方、ステートレス・ルールは、どの相互作用についても想定しません。あるインスタンスから別のインスタンスへのメッセージのみが存在し、ステートレス・ルールは、以前に行ったことに関係なくすべてのものに適用されます。ステートフル・ルールでは、ステートレス・ルールでは処理されない状態を追跡するためにオーバーヘッド処理が必要です。トラフィックが大きく、かつ大きく異なるインスタンス(webサイトなど)では、可能な場合はステートレス・ルールを使用してシステムの負荷を最小限に抑える必要があります。

ノート:

ステートレス・ルールおよびステートフル・ルールを作成する場合は注意が必要です。ステートフル・ルール基準とステートレス・ルール基準の両方を満たすメッセージが表示された場合は、ステートレス・ルールが適用されます。これにより、許可されていると思われるリクエストに対するレスポンスがブロックされます。

VCNには、デフォルトのセキュリティ・リストを使用するサブネットがある場合があります。リストのデフォルト・セキュリティ・ルールは、VCN内のリソースがそれらを必要としないことを最初に確認しないかぎり、削除しないでください。そうしないと、VCN接続が中断する可能性があります。

次の点に留意してください:

セキュリティ・ルールはデフォルトでステートフルですが、ステートレスに構成することもできます。一般的な方法は、高パフォーマンス・アプリケーションにステートレス・ルールを使用することです。ネットワーク・トラフィックがステートフル・セキュリティ・リストとステートレス・セキュリティ・リストの両方と一致する場合、ステートレス・ルールが優先されます。 VCNセキュリティ・ルールの構成の詳細は、Oracle Cloud Infrastructureの「セキュリティ・ルール」を参照してください。
コンピュート・インスタンスへの不正アクセスまたは攻撃を防止するために、Oracleでは、認可されたCIDRブロックからのSSHまたはRDPアクセスのみを許可するVCNセキュリティ・ルール(0.0.0.0/0))を使用することをお薦めします。セキュリティを強化するために、VCN API UpdateNetworkSecurityGroupSecurityRules (ネットワーク・セキュリティ・グループを使用している場合)またはUpdateSecurityList (セキュリティ・リストを使用している場合)を使用して、必要に応じてSSH (ポート22)またはRDP (ポート3389)アクセスを一時的に有効にできます。 RDPアクセスの有効化の詳細は、Oracle Cloud Infrastructureの「インスタンスの作成」の「RDPアクセスを有効にするには」を参照してください。インスタンス・ヘルス・チェックを実行するには、Oracleで、ICMP pingを許可するようにVCNセキュリティ・ルールを構成することをお薦めします。詳細は、「Pingを有効にするルール」 Oracle Cloud Infrastructureを参照してください。

VCNのネットワーク・セキュリティ・グループ(NSG)およびセキュリティ・リストによって、コンピュート・インスタンスに対するセキュリティが重要なネットワーク・アクセス制御が有効になります。NSGおよびセキュリティ・リストの意図しない変更または認可されていない変更を防ぐことが重要です。未承認の変更を防止するために、OracleではIAMポリシーを使用して、ネットワーク管理者のみがNSGおよびセキュリティ・リストの変更を許可することをお薦めします。

VCNのデフォルト・セキュリティ・リストにはステートレス・ルールがありません: すべてのデフォルト・セキュリティ・リスト・ルールはステートフルです。ほとんどの場合、デフォルトのルールを変更して、認可されたサブネットからのインバウンド・トラフィックのみを許可する必要があります。

デフォルトのステートフル・セキュリティ・リストのルールは次のとおりです:

ステートフル・イングレス: 認可されたソースIPアドレスおよび任意のソース・ポートからの宛先ポート22 (SSH)でのTCPトラフィックを許可します。このルールを使用すると、新しいクラウド・ネットワークおよびパブリック・サブネットを簡単に作成でき、Linuxインスタンスを起動し、ただちにSSHを使用してそのインスタンスに接続できます。セキュリティ・リスト・ルールは自分で記述する必要はありません。
ステートフル・イングレス: 承認されたソースIPアドレスからのICMPトラフィック・タイプ3コード4を許可します。このルールにより、インスタンスはPath MTU Discoveryフラグメンテーション・メッセージを受信できます。
ステートフル・イングレス: VCN CIDRブロックからのICMPトラフィック・タイプ3 (すべてのコード)を許可します。このルールにより、インスタンスがVCN内の他のインスタンスから接続エラー・メッセージを受信しやすくなります。
ステートフル・エグレス: すべてのトラフィックを許可します。これにより、インスタンスは任意の宛先への任意の種類のトラフィックを開始できます。これは、VCNにインターネット・ゲートウェイが構成されている場合、パブリックIPアドレスを持つインスタンスが任意のインターネットIPアドレスと通信できることを意味します。また、ステートフル・セキュリティ・ルールでは接続トラッキングが使用されるため、イングレス・ルールに関係なくレスポンス・トラフィックが自動的に許可されます。

ノート:

デフォルトのセキュリティ・リストには、リモート・デスクトップ・プロトコル(RDP)アクセスを許可するルールは含まれていません。 Microsoft Windowsイメージを使用している場合は、認可されたソースIPアドレスおよび任意のソース・ポートから宛先port 3389のTCPトラフィックのステートフル・イングレス・ルールを追加してください。

デフォルト・セキュリティ・リストには、pingリクエストを許可するルールは含まれていません。インスタンスをpingすることを計画している場合は、インスタンス適用可能なセキュリティ・リストに、ping元のソース・ネットワークからのICMPトラフィック・タイプ8を明示的に許可する追加のステートフル・イングレス・ルールが含まれていることを確認してください。データ・センターからのpingアクセスを許可するには、ソースに0.0.0.0/0を使用します。 pingのこのルールは、デフォルト・セキュリティ・リストのデフォルトのICMP関連ルールとは異なります。これらのルールは削除しないでください。

ステートレス・セキュリティ・ルールを使用してVCN外のエンドポイントとの間のトラフィックを許可する場合は、ソース0.0.0.0/0および任意のソース・ポートからのイングレスICMPトラフィック・タイプ3コード4を許可するセキュリティ・ルールを追加することが重要です。このルールにより、インスタンスはPath MTU Discoveryフラグメンテーション・メッセージを受信できます。このルールは、インスタンスへの接続を確立するために重要です。そうしないと、接続性の問題が発生する可能性があります。

インスタンスはUDPトラフィックを送受信できます。場合によっては、小さいMTUサイズを持つリンクでUDPパケットが断片化されることがあります。 UDPパケットが接続サイズの制限に対して大きすぎる場合は、フラグメント化されます。ただし、パケットの最初のフラグメントにのみプロトコルおよびポート情報が含まれます。このイングレスまたはエグレス・トラフィックを許可するセキュリティ・ルールで特定のポート番号(ソースまたは宛先)が指定されている場合は、最初のものより後のフラグメントが削除されます。インスタンスが大きなUDPパケットを送受信することを期待する場合は、適用可能なセキュリティ・ルールのソース・ポートと宛先ポートの両方を(特定のポート番号ではなく)ALLに設定します。

セキュリティ・リストでは、サブネット全体のすべてのVNICに適用されるセキュリティ・ルールのセットが定義されます。特定のサブネットで特定のセキュリティ・リストを使用するには、サブネットの作成時または作成後にセキュリティ・リストをサブネットに関連付けます。サブネットは最大5つのセキュリティ・リストに関連付けることができます。そのサブネットに作成されたVNICは、そのサブネットに関連付けられたセキュリティ・リストに従います。

ネットワーク・セキュリティ・グループを使用したトラフィックの制御

セキュリティ・リスト・ルールをネットワーク・セキュリティ・グループ(NSG)に収集すると、一連のルールの適用をVNICのグループ化が容易になります。 NSGを使用すると、選択したVNICのグループ(またはロード・バランシングやDBシステムなどのVNICの親リソース)に適用されるセキュリティ・ルールのセットを定義できます。すべてのセキュリティ状態が同じ「コンピュート・エンクレーブ」インスタンスのセットに属するVNICは、NSGを使用してルールのセットを適用できます。

特定のNSGを使用するには、目的のVNICをグループに追加します。そのグループに追加されたVNICは、そのグループ・セキュリティ・ルールの対象となります。 VNICは最大5つのNSGに追加できます。

重要:

NSGではVCNサブネット・アーキテクチャをアプリケーション・セキュリティ要件から分離できるため、Oracleではセキュリティ・リストではなくNSGを使用することをお薦めします。

ただし、必要な場合は、セキュリティ・リストとNSGの両方を使用できます。実際、NSGを使用する必要はありません。また、NSGは、すべてのタイプのOracle Private Cloud Applianceサービスでサポートされるわけではありません。

現在、次のタイプの親リソースはNSGの使用をサポートしています:

コンピュート・インスタンス: インスタンスを作成する際、インスタンスのプライマリVNICに1つ以上のNSGを指定できます。セカンダリVNICをインスタンスに追加する場合、そのVNICに1つ以上のNSGを指定できます。また、インスタンスの既存のVNICを更新して、1つ以上のNSGに含まれるようにすることもできます。
マウント・ターゲット: ファイル・システムのマウント・ターゲットを作成する場合は、1つ以上のNSGを指定できます。 1つ以上のNSGを使用するように既存のマウント・ターゲットを更新することもできます。
DNSリゾルバ・エンドポイント: プライベートDNSリゾルバのエンドポイントを作成する際、1つ以上のNSGを指定できます。既存のエンドポイントを更新して、1つ以上のNSGを使用することもできます。

NSGをサポートしていないリソース・タイプの場合、引き続きセキュリティ・リストを使用して、これらの親リソースとの間のトラフィックを制御します。

NSGの操作は、次の3つのステップ・プロセスです:

NSGを作成します。
セキュリティ・ルールをNSGに追加します。
NSGに親リソース(具体的にはVNIC)を追加します。親リソースの作成時にこれを実行することも、親リソースを更新して1つ以上のNSGに追加することもできます。コンピュート・インスタンスを作成してNSGに追加すると、インスタンスのプライマリVNICがNSGに追加されます。別に、セカンダリVNICを作成し、オプションでNSGに追加できます。

NSGを削除する前に、NSGからすべてのVNICを削除する必要があります。

VCNゲートウェイのセキュアな接続

VCNゲートウェイは、外部接続(インターネット、オンプレミスまたはピアリングVCN)をVCNホストに提供します。ゲートウェイ・タイプのリストについては、このガイドの「ネットワーキングのセキュリティ機能」セクションの最初にある表を参照してください。 Oracleでは、IAMポリシーを使用して、ネットワーク管理者のみがVCNゲートウェイを作成または変更できるようにすることをお薦めします。

すべてのインスタンスに対するインターネット・アクセスの許可は慎重に検討してください。たとえば、機密データベース・インスタンスへのインターネット・アクセスを誤って許可しないようにします。 VCN内のインスタンスを「インターネットからパブリックにアクセス可能」にするには、次のVCNオプションを構成する必要があります:

インスタンスは、VCNパブリック・サブネット内にあることが必要です。
インスタンスが含まれるVCNは、インターネット・ゲートウェイが有効になっており、アウトバウンド・トラフィックのルーティング・ターゲットとして構成されている必要があります。
インスタンスには、パブリック・サブネットへのインターネット・ゲートウェイ(パブリックIPを持つインスタンスの場合)またはプライベート・サブネットへのネットワーク・アドレス変換(NAT)ゲートウェイ(プライベートIPを持つインスタンスの場合)のいずれかのパブリックIPアドレスが割り当てられている必要があります。
インスタンス・サブネットのVCNセキュリティ・リストは、0.0.0.0/0からのインバウンド・トラフィックを許可するように構成する必要がありますが、特定の宛先ポートおよびIPプロトコルに対してのみ構成する必要があります。または、ネットワーク・セキュリティ・グループ(NSG)を使用している場合は、そのトラフィックを許可するNSGにインスタンスが存在する必要があります。

VCNゲートウェイのセキュリティの詳細は、「Oracle Private Cloud Appliance概要ガイド」の「ネットワーク・セキュリティ」に関する項を参照してください

DNSのセキュリティ機能

DNSゾーンおよびレコードは、webプロパティのアクセシビリティにとって重要です。更新が正しくないか、承認されていない削除によってサービスが停止し、DNS名を介してアクセスされる可能性があります。 Oracleでは、DNSゾーンおよびレコードを変更できるIAMユーザーを制限することをお薦めします。

Oracle Private Cloud Appliance DNSはDNSSECを使用します。 DNSSECには、「DNSSEC脆弱性」の外部kサイトで議論されている脆弱性があります。

VCNセキュリティ・ポリシーの例

VCNのセキュリティ・ポリシーの例を3つ示します:

ユーザーにセキュリティ・リストの表示のみを許可
- ネットワーク管理者は、ネットワーク・セキュリティ・グループおよびセキュリティ・リストを作成および管理する権限を持つ必要があります。
- 次のポリシー例の最初の行は、NetworkUsersグループがセキュリティ・リストとその内容を表示することを許可します。このポリシーによって、このグループがセキュリティ・リストの作成、アタッチ、削除または変更を行うことはできません。
- 2行目では、NetworkUsersグループがNSGのセキュリティ・ルールを表示し、NSGにあるVNICおよび親リソースも表示できます。 2行目では、NetworkUsersグループはNSGのセキュリティ・ルールを変更できません。
```
"Allow group NetworkUsers to inspect security-lists in tenancy"
"Allow group NetworkUsers to use network-security-groups in tenancy"                                    
```
ユーザーによるインターネットへの外部接続の作成を防止
- 場合によっては、ユーザーがVCNに対する外部インターネット接続を作成できないようにする必要があります。次のポリシー例では、NetworkUsersグループがインターネット・ゲートウェイの作成を禁止されています。
```
"Allow group NetworkUsers to manage internet-gateways in tenancy 
where request.permission!='INTERNET_GATEWAY_CREATE'"
```

ユーザーがDNSレコードおよびゾーンを更新できないようにします

次のポリシー例では、NetworkUsersグループがDNSゾーンおよびレコードを削除および更新できません。

"Allow group NetworkUsers to manage dns-records in tenancy
 where all {request.permission!='DNS_RECORD_DELETE', 
            request.permission!='DNS_RECORD_UPDATE'}"

"Allow group NetworkUsers to manage dns-zones in tenancy
 where all {request.permission!='DNS_ZONE_DELETE', 
            request.permission!='DNS_ZONE_UPDATE'}"

VCNセキュリティのための便利なCLIコマンド

次のすべての例では、環境変数$Cおよび$VCNがコンパートメントOCIDおよびVCN OCIDにそれぞれ設定されています。

VCN内のオープン・セキュリティ・リストのリスト

# list open (0.0.0.0/0) security lists in VCN $VCN in compartment $C 
oci network security-list list -c $C --vcn-id $VCN | grep "source" | grep "\"0.0.0.0/0\""

VCNのゲートウェイのリスト表示

# list all internet gateways in VCN $VCN in compartment $C 
oci network internet-gateway list -c $C --vcn-id $VCN 
# list all DRGs in compartment $C 
oci network drg list -c $C 
# list all local peering gateways in vcn $VCN in compartment $C 
oci network local-peering-gateway list -c $C --vcn-id $VCN

VCNのルート表ルールのリスト表示

# list route table rules in VCN $VCN in compartment $C 
oci network route-table list -c $C --vcn-id $VCN

コンピュート・サービスのセキュリティ機能

コンピュート・サービスのコア機能は、コンピュート・インスタンスと、インスタンス構成、インスタンス・プール、カスタム・イメージなどの関連リソースです。コンピュート・サービスは複数のサービスに依存: ブート・イメージおよびボリューム拡張用のブロック・ボリューム、接続用のネットワーキングおよびイメージ・インポート用のオブジェクト・ストレージ。

次のことが必要です。

ブロック・ボリューム、ネットワークおよびオブジェクト・ストレージに対して、制限的で最小限のアクセス、IAMポリシーおよび手法を適用します。これは、カスタム・イメージの悪意のある使用を防止し、コンピュート・インスタンスがネットワークにアクセスできないようにするために不可欠です。
構成およびデプロイされたリソースへの変更を防ぐために、制限的で最小限の権限アクセスをコンピュート・サービスに適用します。

クリティカルなインスタンス(本番インスタンスなど)の不注意または悪意のある終了を防止するために、Oracleでは最小限のグループのセットにINSTANCE_DELETE権限を付与することをお薦めします。テナンシ管理者およびコンパートメント管理者にのみDELETE権限を付与します。インスタンス・ポリシーの例については、このガイドの「インスタンス・セキュリティ・ポリシーの例」の項を参照してください

インスタンス・メタデータ・アクセス制御

インスタンス・メタデータ(http://169.254.169.254)には、OCID、表示名、カスタム・フィールドなどの事前定義済インスタンス情報が表示されます。 Oracleでは、インスタンス・メタデータ・アクセスをインスタンス上の特権ユーザーに制限することをお薦めします。次の例は、iptablesを使用して、ルート・ユーザーへのインスタンス・メタデータ・アクセスを制限する方法を示しています。

iptables -A OUTPUT -m owner ! --uid-owner root -d 169.254.169.254 -j DROP

インスタンスでは、リンク・ローカル・アドレスを使用してインスタンス・メタデータ・サービス(169.254.169.254:80)、DNS (169.254.239.254:53)およびNTP (169.254.169.254:123)にアクセスします。 iptablesなどのホスト・ベースのファイアウォールを使用して、これらのIPへのアクセスをrootユーザーのみが認可されるようにできます。これらのオペレーティング・システムのファイアウォール・ルールが変更されていないことを確認してください。

インスタンス・ネットワーク・アクセス制御

Oracle Linuxコンピュート・インスタンスには、従うべき様々なベスト・プラクティスがあります。他のオペレーティング・システム・タイプでも同様の制限があります。

セキュリティの推奨事項	構成sshd_config	コメント
公開キー・ログインのみを使用	PubkeyAuthenticationはい	次のSSH公開キーを定期的に確認 `~/.ssh/authorized_keys` file
パスワード・ログインの無効化	PasswordAuthenticationなし	パスワード・ルート・フォース攻撃を軽減
rootログインを無効にします	PermitRootLoginなし	リモート・ログインのルート権限を防止
SSHポートを非標準のポート番号に変更	ポート <port-number>	(オプション) SSHでポート22を使用する変更でアプリケーションが破損しないことを確認します。

さらに、次もあります。

すべてのインスタンスでセキュア・シェル(SSH)を強化します。次の表にSSHセキュリティの推奨事項をいくつか示します。 SSH構成オプションは、sshd_configファイル(Linuxの/etc/ssh/sshd_configにあります)で設定できます。
セキュアなSSH秘密キーを使用して、インスタンスにアクセスし、不注意な開示を防止します。 SSHキー・ペアの作成とキーを使用したインスタンスの構成の詳細は、「Linuxインスタンスでのキー・ペアの管理」を参照してください。
許可されたIPアドレスへのインスタンス・アクセスを制限するには、VCNネットワーク・セキュリティ・グループまたはセキュリティ・リストを使用します。 Fail2banは、ルート・フォース・サインイン試行(インスタンスのサインインに失敗した試行が多すぎる)に関連するIPアドレスをブロック・リスト表示するアプリケーションです。デフォルトでは、Fail2banはSSHアクセスを検査し、他のプロトコルを検査するように構成できます。 Fail2banの詳細は、GitHubのfail2banを参照してください。
VCNネットワーク・セキュリティ・グループおよびセキュリティ・リストに加えて、iptablesやfirewalldなどのホスト・ベースのファイアウォールを使用して、ポート、プロトコルおよびパケット・タイプの制御によってインスタンスへのネットワーク・アクセスを制限します。これらのファイアウォールを使用して、ポートのスキャンや侵入の試行など、潜在的なネットワーク・セキュリティ攻撃の偵察を防止します。カスタム・ファイアウォール・ルールは、起動するインスタンスごとに構成、保存および初期化できます。

次の例は、iptablesのコマンドを示しています:
```
# save iptables rules after configuration 
sudo iptables-save > /etc/iptables/iptables.rules 
# restore iptables rules on next reboot 
sudo /sbin/iptables-restore < /etc/iptables.rules 
# restart iptables after restore 
sudo service iptables restart            
```

インスタンス・エントロピ

インスタンスには、オペレーティング・システムによって使用されるエントロピ・プールに出力が供給される乱数ジェネレータがあります。 Linuxインスタンスでは、/dev/randomは非ブロッキングであり、乱数を必要とするセキュリティ・アプリケーションに使用する必要があります。次のコマンドを使用して、アプリケーションで出力を使用する前に、/dev/randomによって生成された乱数のスループットと品質を確認できます。

# check sources of entropy 
sudo rngd -v 
# enable rngd, if not already 
sudo systemctl start rngd 
# verify rngd status 
sudo systemctl status rngd 
# verify /dev/random throughput and quality using rngtest 
cat /dev/random | rngtest -c 1000

ホスト・セキュリティの強化とパッチ適用

インスタンスで実行されているLinuxおよびMicrosoft Windowsイメージのセキュリティ強化のベースラインを確立します。 Oracle Linuxイメージのセキュリティ強化の詳細は、「Oracle Linuxサーバーを強化するためのヒント」を参照してください。「Center for Internet Securityベンチマーク」は、LinuxおよびMicrosoft Windowsサーバーの様々なディストリビューションのオペレーティング・システム・セキュリティ強化ベンチマークの包括的なセットを提供します。

インスタンス・ソフトウェアは、セキュリティ・パッチを使用して最新の状態に維持します。 Oracleでは、使用可能な最新のソフトウェア更新をインスタンスに定期的に適用することをお薦めします。

注意:

pca*チャネルからのみパッチをインストールします。他のチャネルとその他のメソッドを使用してアプライアンスを手動で更新することはサポートされていません。 OL7に対するセキュリティおよびその他の更新は、pca*チャネルを介して行われます。詳細は、「Oracle Private Cloud Appliance管理者ガイド」の「パッチ適用のための環境の構成」を参照してください。

Oracle Linuxイメージの場合は、yumおよびdnf構成を確認し、VCNからリポジトリおよびソフトウェア・ストリームにアクセスできることを確認します。

コンピュート・インスタンスを更新します。 Oracle Linux 7およびOracle Linux 8のソフトウェア更新の詳細は、( 「Oracle Linux Yum Serverの開始」)を参照してください。

更新されたインスタンスに基づいて新しいイメージを作成する必要がある場合は、「Oracle Private Cloud Applianceユーザー・ガイド」の「コンピュート・イメージ」の章の「インスタンスからのイメージの作成」の項を参照してください。

インスタンス・セキュリティのロギングおよびモニタリング

各コンピュート・インスタンスのログ・ファイルに、様々なセキュリティ関連イベントが取得されます。 Oracleでは、これらのログ・ファイルを定期的に確認してセキュリティの問題を検出することをお薦めします。 Oracle Linuxでは、ログ・ファイルは/var/logにあります。次の表に、セキュリティ関連のログファイルとそのロケーションの一部を示します。

ログ・ファイルまたはディレクトリ	説明
`var/log/secure`	失敗したサインインおよび成功したサインインを示す認可ログ。
`var/log/audit`	発行されたシステム・コール、`sudo`試行、ユーザー・サインインなどを取得するAuditdログ。`ausearch`および`aureport`は、auditdログの問合せに使用される2つのツールです。
`var/log/yum.log`	yumを使用してインスタンスにインストールまたは更新されたパッケージをリストします。
`var/log/cloud-init.log`	インスタンスの起動中に、cloud-initはユーザー指定のスクリプトを特権ユーザーとして実行できます。たとえば、`cloud-init`はSSHキーを導入できます。 Oracleでは、認識されないコマンドの`cloud-init`ログを確認することをお薦めします。

インスタンス・セキュリティ・ポリシーの例

次のすべての例で、ポリシーはテナンシにスコープ指定されます。ただし、コンパートメント名を指定することによって、テナンシ内の特定のコンパートメントを対象範囲に絞り込むことができます。

インスタンスを削除できるユーザーの制限

次の例では、InstanceUsersグループはインスタンスを起動できますが、削除はできません。

"Allow group InstanceUsers to manage instance-family in tenancy
 where request.permission!='INSTANCE_DELETE'"
"Allow group InstanceUsers to use volume-family in tenancy"
"Allow group InstanceUsers to use virtual-network-family in tenancy"

インスタンス・コンソールを使用する制限機能

セキュリティ・コンプライアンスの理由から、一部の顧客はインスタンス・コンソールをテナンシのユーザーに公開したくありません。次のポリシーの例は、コンソールでの作成または読取り権限を制限します。

"Allow group InstanceUsers to manage instance-console-connection in tenancy
 where all {request.permission!= INSTANCE_CONSOLE_CONNECTION_READ, 
            request.permission!= INSTANCE_CONSOLE_CONNECTION_CREATE}"

Block Volumeのセキュリティ機能

ボリュームには2つのタイプがあります: ブロック・ボリュームおよびブート・ボリューム。ブロック・ボリュームを使用すると、インスタンス・ストレージ容量を動的に拡張できます。ブート・ボリュームには、コンピュート・インスタンスの起動に使用されるイメージが含まれます。

IAMサービスは、関連するボリューム・リソース・タイプのファミリをvolume-familyという結合リソース・タイプにグループ化します。

さらに、ブロック・ボリュームには次の特徴があります:

Advanced Encryption Standard (AES) 128ビット・アルゴリズムを使用してディスク上で暗号化されます(保存時)。暗号化は既定でオンになっているため、オフにできません。暗号化キー自体は、マスター暗号化キーを使用して暗号化されます。
ボリュームは、dm-crypt、veracrypt、Bit-Lockerなどのツールを使用してさらに暗号化できます。
Oracle Private Cloud Applianceに対して認証されたユーザーは、ボリュームを管理し、セキュリティ・ポリシー・フレームワーク内でリソースを管理できます。

IAMユーザーおよびグループの最小権限アクセスをvolume-familyのリソース・タイプに割り当てます。 volume-familyのリソース・タイプは、volumes、volume-attachmentsおよびvolume-backupsです。

ブロック・ボリュームのデータ耐久性

ブロック・ボリュームは、SHA-256チェックサムを使用してZFSファイル・システムに格納されるため、ファントム読取りを回避し、デバイスから返された無効なデータを検出できます。

認可されたユーザーによる不注意な削除または悪意のある削除によるデータの損失を最小限に抑えるために、Oracleでは、IAMユーザーおよびグループの可能な最小セットにVOLUME_DELETE、VOLUME_ATTACHMENT_DELETEおよびVOLUME_BACKUP_DELETE権限を付与することをお薦めします。 DELETE 権限は、テナンシ管理者およびコンパートメント管理者にのみ付与する必要があります。

削除または破損によるデータの損失を最小限に抑えるために、Oracleではボリュームを定期的にバックアップすることをお勧めします。 Oracle Cloud Infrastructureでは、スケジュールされた自動バックアップが可能です。スケジュール済バックアップの詳細は、「ポリシーベースのバックアップ」を参照してください。

ブロック・ボリューム・セキュリティ・ポリシーの例

ボリュームの削除の防止

次のポリシーの例では、グループVolumeUsersは、ボリュームおよびバックアップに対する削除を除くすべてのアクションを実行できます:

"Allow group VolumeUsers to manage volumes in tenancy
 where request.permission!='VOLUME_DELETE'"
"Allow group VolumeUsers to manage volume-backups in tenancy
 where request.permission!='VOLUME_BACKUP_DELETE'"

VolumeUsersがインスタンスからボリュームをデタッチできない場合は、次のポリシーを前の例に追加できます:

"Allow group VolumeUsers to manage volume-attachments in tenancy
 where request.permission!='VOLUME_ATTACHMENT_DELETE'"

dm-cryptを使用したルート以外のボリュームの暗号化

dm-cryptは、暗号化ボリュームを提供するカーネル・レベルの暗号化メカニズム(Linuxデバイス・マッパー・フレームワークの一部)です。ファイルシステム(たとえば、ext4およびNTFS)から渡されるデータを暗号化し、Linux Unified Key Setup (LUKS)形式でストレージ・デバイスに格納します。暗号化されたボリュームは、完全なディスク、ディスク・パーティション、論理ボリューム、またはループバック・デバイスを使用して作成されたファイル・バックアップ・ストレージに格納できます。cryptsetupは、dm-cryptの管理に使用されるユーザー・レベルのユーティリティで、パーティションおよびファイルの暗号化に使用されます。dm-cryptは、暗号化ルーチンにLinux暗号化APIを使用します。

ボリュームを暗号化するには:

ブロック・ストレージ・ボリュームをインスタンスにアタッチします(/dev/sdbなど)。
LUKS暗号化の場合は/dev/sdbをフォーマットします。要求されたら、LUKSパスフレーズを入力します。ボリュームの暗号化に使用されるLUKSマスター・キーの暗号化には、パスフレーズが使用されます。
```
cryptsetup -y luksFormat /dev/sdb
```
LUKSのフォーマットが成功したことを確認します。
```
cryptsetup isLuks /dev/sdb && echo Success
```
デバイスに関する暗号化情報を取得します。
```
cryptsetup luksDump /dev/sdb
```
デバイスのLUKS UUIDを取得します。 UUID値は、/etc/crypttabを構成するために使用されます。
```
cryptsetup luksUUID /dev/sdb
```
デバイス名dev_nameのLUKSコンテナを作成します。これにより、デバイス・ノード/dev/mapper/<dev_name>も作成されます。
```
cryptsetup luksOpen /dev/sdb <dev_name>
```
マップされたデバイスの情報を取得します。
```
dmsetup info <dev_name>
```
デバイス・ノードをext4ファイルシステムとしてフォーマットします。
```
sudo mkfs -t ext4 /dev/sdb 
```
デバイス・ノードをマウントします。
```
mount /dev/mapper/<dev_name> /home/encrypt_fs
```
/etc/crypttabにエントリを追加します。
```
<dev_name> UUID=<LUKS UUID of /dev/sdb> none
```
/home/encrypt_fsにコピーされるファイルはすべてLUKSによって暗号化されます。
暗号化されたボリュームの使用可能なキー・スロットにキー・ファイルを追加します。このキー・ファイルは、暗号化されたボリュームにアクセスできます。
```
dd if=/dev/urandom of=$HOME/keyfile bs=32 count=1
chmod 600 $HOME/keyfile
cryptsetup luksAddKey /dev/sdb ~/keyfile
```
ファイルの暗号化ステータスを確認します。
```
cryptsetup status /home/encrypt_fs
```

終了後にアンマウントします。

umount /home/encrypt_fs
cryptsetup luksClose <dev_name>

暗号化したボリュームにアクセスするには:

cryptsetup luksOpen /dev/sdb <dev_name> --key-file=/home/opc/keyfile
mount /dev/mapper/<dev_name> /home/encrypt_fs

キー・ファイルを失った場合、またはキー・ファイルまたはパスフレーズが破損した場合は、暗号化されたボリュームを復号化できません。

Oracleでは、キー・ファイルの永続コピーをオンプレミス・ホストに格納することをお薦めします。

dm-crypt暗号化データ・ボリュームのリモート・マウント

次のステップでは、キー・ファイルがオンプレミス・ホスト(SRC_IP)にあり、<OCI_SSH_KEY>がインスタンスのSSH秘密キーであることを前提としています。

「コンピュート・エンクレーブ」セキュリティ機能