2 Oracle Private Cloud Applianceのセキュアなインストールおよび構成
Oracle Private Cloud Applianceはエンジニアド・システムであり、インストールは通常顧客に対して実行されます。 システムの電源をはじめて投入したときに、システムを初期設定するために実行する必要があるさまざまなタスクがあります。 最初の「admin」ユーザー・アカウントの定義(セキュリティ要件によりデフォルトの管理者アカウントが提供されなくなったこと、レルムやリージョンなどのシステム・パラメータの構成、基本的なネットワーク・パラメータの構成など)などのタスク。 Oracle Private Cloud Applianceは、オペレータがシステム情報を表示および構成するための2つの方法をサポートしています: GUIおよびセッション・ベースのCLI。 初期インストールでは、GUIを使用してオペレータに必要なさまざまな初期構成をガイドすることが想定されています。 必要に応じて、オペレータはCLIを使用してこれらのアクションを代わりに実行できます。
インストールの概要
エンジニアド・システムとして、Oracle Private Cloud Applianceのインストールは通常、お客様が実行するものではありません。 ただし、セキュリティ上の懸念は、システムを使用するすべてのユーザーの責任です。 セキュリティ問題は、あとでシステムに追加できないため、システムのインストール前に対処する必要があります。
インストール前のセキュリティ詳細
Oracle Private Cloud Applianceインストールの前に、提供されるサービスの概要を示すドキュメントを作成します。 欠点に対応できるようにレビューおよび更新しました。
-
各アプリケーションまたはサービスについて、セキュリティを担当するユーザーに情報をレビューしてもらいます。
-
レビュー担当者がインストール前プランの作成に使用するソース資料を簡単に見つけられるように、必要なすべてのURLとリンクを提供します。
-
すべてのレビュー担当者が、すべての初期セキュリティ目標が満たされるまで、プロセスを繰り返します。
Oracle Private Cloud Applianceをセキュアな環境にデプロイするために必要なすべてのロールのリストを作成します。 これらのロールを満たすために必要な担当者を特定します。
ノート:
識別されたロールとユーザーが重複せず、その機能が適切に分離されていることを確認します。
-
Oracle Private Cloud Applianceのすべてのレイヤーに対する様々な管理者の理解: インフラストラクチャ、サービス・エンクレーブおよびコンピュート・エンクレーブ。
-
Oracle Private Cloud Applianceのすべての関連レイヤーでサービスのユーザーを識別します。 必要な特権と必要な制限を一覧表示します。
Oracle Private Cloud Applianceに必要な仮想マシンおよびネットワーク接続を使用して、ドラフト実装計画を作成します。 インストール前に完了するまで、これを確認して変更してください。
-
各仮想マシンのロールをできるだけ明確に説明してください。
-
一般的なフロントエンド、バックエンド、およびロード・バランサの配置からの出発点がある場合は、すべて記述してください。
-
仮想マシンの起動の状況(初期使用と増加したロードの処理の両方)の説明。
Oracle Private Cloud Applianceアーキテクチャの各レイヤーの仮想マシン間で必要なネットワーク接続(ある場合)を説明します。
-
システムの動作および保守に使用するセキュアなネットワーク・プロトコルを一覧表示します。
-
仮想マシン通信の初期ポリシー・ルールを少なくともproseレベルで指定します。
-
切り替え可能なネットワーク接続の特定: つまり、単純なVLANと単一のIPアドレス空間によって処理できます。
-
どのネットワーク接続をルーティングする必要があるかを決定: つまり、複数のVLANおよびサブネット化されたIPアドレス空間の倍数によって処理される必要があります。
製品のインストール
Oracle Private Cloud Applianceをインストールしたユーザーに関係なく、Oracle Private Cloud Appliance製品の各コンポーネントは自動的にセキュアな状態にインストールされます。 SSLなどのセキュリティ・オプションは、すでに構成されて有効化されています。
セキュリティが損なわれないかぎり、インストールされている製品を特定のデプロイメント・シナリオに合わせて調整できます。
特定のデプロイメントで使用されていないシステムの任意のコンポーネントをアンインストールまたは無効化できます。
インストール後の構成
このセクションでは、インストール後に行う必要があるセキュリティ構成の変更について説明します。 通常、構成を変更するときにOracle Private Cloud Applianceのセキュリティ状態を弱めることはできません。
ハードウェアの保護
Oracle Private Cloud Applianceのインストール後、ハードウェアへのアクセスを制限し、シリアル番号を記録することによってハードウェアをセキュリティ保護します。
アクセスを制限する措置として、次のことをお薦めします。
-
Oracle Private Cloud Applianceおよび関連する機器をロックされたアクセス制限のある部屋に取り付けます。
-
ラック内のコンポーネントでサービスが必要でない場合は、ラックのドアに鍵を掛けます。
-
コンポーネントは簡単に取り外せるように設計されているため、ホット・プラグ可能またはホット・スワップ可能なデバイスへのアクセスを制限します。
-
予備の現場交換可能ユニット(FRU)または顧客交換可能ユニット(CRU)は鍵の掛かったキャビネットに保管します。 鍵の掛かったキャビネットへは、認可された人のみがアクセスできるように制限します。
-
SSHリスナー・ポートを管理ネットワークおよびプライベート・ネットワークに制限します。 SSHプロトコル2 (SSH-2)およびFIPS 140-2承認暗号を使用します。
-
SSHが許可される認証メカニズムを制限します。 本質的にセキュアでない方法は無効化されます。
-
すべての主要なコンピュータ・ハードウェア・アイテム(FRUなど)にラベルを付けます。
-
ハードウェアのアクティベーション・キーとライセンスは、システム緊急時にシステム・マネージャが簡単に取り出せる安全な場所に保管します。
アプライアンスのシリアル番号の取得
Oracle Private Cloud Applianceには、アプライアンスをエンティティ全体として識別するシリアル番号があります。 Oracle Support Servicesを操作する場合は、アプライアンスのシリアル番号が必要になることがあります。
ラックにはシリアル番号のラベルが付いています。 シリアル番号ラベルは、ラックの右前レールの真ん中上にある白色のラベルです。
-
「サービス・エンクレーブ」コンソールの使用(管理コンソール) - 「サービス・エンクレーブ」コンソールからアプライアンスのシリアル番号を取得するには:
-
サポートされているwebブラウザを使用して、十分な認可(
https://adminconsole.<domain>
)があるユーザー名とパスワードでコンソールにログインします。 -
初期設定を完了したばかりの場合は、構成されたパスワードで管理ユーザー名を使用します(そうでない場合は、管理者がアクセス用に特定のユーザーを提供できます)。
-
メニューから「アプライアンス詳細」セクションにアクセスします。
-
このページからIDとレルムを記録します。 レルムは物理アプライアンスのシリアル番号です: IDと物理アプライアンスのシリアル番号の両方を記録します。
-
-
適切なモニタリング・ダッシュボードの使用( Grafana) - モニタリング・ダッシュボードからアプライアンスのシリアル番号を取得するには:
-
サポートされているwebブラウザを使用して、十分な認可を持つユーザー名とパスワード(
https://grafana.<domain>
)を使用してダッシュボードにログインします。 -
ダッシュボード→「ダッシュボードの管理」セクションに移動します。
-
Service Monitoring→Hardware Statsダッシュボードを開きます。 このダッシュボードにはアプライアンスのシリアル番号が表示されます。
-
このページからIDとレルムを記録します。 レルムは物理アプライアンスのシリアル番号です: IDと物理アプライアンスのシリアル番号の両方を記録します。
-
-
管理コマンドライン・インタフェース(CLI)の使用 - CLIを使用してアプライアンスのシリアル番号を取得するには:
-
十分な認可を持つユーザー名とパスワードで管理CLIにログインします(コマンドssh -l <username> management host -p 30006を使用します)。 管理ホストは3つの管理ノード(
pcamn01
、pcamn02
またはpcamn03
)のいずれかであり、ユーザー名はデフォルトでadmin
です。 パスワードのローテーションに関するセクションがまだ完了していない場合は、初期設定時に指定したパスワードを使用します。 -
プロンプトから、ラックのシリアル番号を取得するためのさまざまな方法があります。 クイック・レポートは、コマンドで取得できます: list Rack fields name,rackNumber,rackSerialnumber,rackType.
たとえば、
PCA-ADMIN> list Rack fields rackSerialnumber Command: list Rack fields rackSerialnumber Status: Success Time: 2022-02-17 20:15:41,773 UTC Data: id rackSerialnumber -- ---------------- x6d9f31a-b1ds-4a43-bc09-7270609abd8k CL00888510 PCA-ADMIN>
-
アプライアンス詳細の情報をセキュアなロケーションに格納します。
-
ラック内のハードウェア・コンポーネントのシリアル番号の取得
Oracle Private Cloud Applianceは、多くのハードウェア・コンポーネントで構成されるエンジニアド・システムです。 わかりやすくするために、これらのコンポーネントをrackコンポーネントと呼びますが、コンポーネントは複数のラックにまたがることができます。 ラック・コンポーネントのシリアル番号を収集する最も効率的な方法は、管理CLIを使用することです。ただし、これらは「サービス・エンクレーブ」コンソール(管理コンソール)から取得することもできます。 これらのシリアル番号は、Oracle Support Servicesを操作するときにも必要になる場合があります。
管理CLIからラック・コンポーネントのシリアル番号のリストを取得するには:
-
十分な認可を持つユーザー名とパスワードで管理CLIにログインします(コマンドssh -l <username> management host -p 30006を使用します)。 詳細は、「アプライアンスのシリアル番号の取得」セクションを参照してください。
-
ログインしたら、次のようなコマンドを使用してレポートを取得: list RackUnit fields name,rackElevation,serialNumber,hostname.
-
上記で記録した情報を安全なロケーションに保存します。
「サービス・エンクレーブ」コンソールを使用するには、十分な認可(https://adminconsoleを持つユーザー名とパスワードでコンソールにログインします。<domain>)。 ログイン後:
-
メニューを使用して、Rack Unitsコンテキストに移動します。
-
リスト内のユニットごとに、詳細の表示を選択します:
-
詳細が表示されたら、システム・タブを選択します。
-
その他のコンポーネント情報とともにシリアル番号を記録します。
-
-
Rack Unitsリストに戻り、次のコンポーネントを記録します。
-
上記で記録した情報を安全なロケーションに保存します。
ソフトウェアの保護
Oracle Private Cloud Applianceのインストール後、ソフトウェアをセキュリティ保護します。 多くの場合、ハードウェア・セキュリティはソフトウェアを介して実装されます。
Oracle Private Cloud Applianceの初期インストール後、Oracleでは、システム・アクセスを制限するために次の演習を推奨します:
-
管理ノードではroot、「サービス・エンクレーブ」および「コンピュート・エンクレーブ」ではSuperAdminアカウントなど、スーパーユーザー・アカウントの使用を制限します。 個々のユーザー・アカウントを作成して使用すると、監査証跡での肯定的な識別が保証され、管理者がチームまたは会社を離れた場合のメンテナンスが減ります。
-
管理ノードで新規ユーザーを作成しないでください。
-
顧客が管理する層の不要なプロトコルとモジュールを無効にします。
-
物理セーバーとネットワーク・スイッチにはシステムへの直接アクセスを提供するポートとコンソール接続があるため、USBポート、ネットワーク・ポート、およびシステム・コンソールへの物理アクセスを制限してください。
-
ネットワークを介してシステムを再起動する機能を制限します。
-
その他のセキュリティ機能を有効にする方法の詳細は、このガイドの「Oracle Private Cloud Applianceのセキュリティ機能」を参照してください。
特権ユーザーとマルチ・ファクタ・アクセス制御、およびデータ暗号化、監査、モニタリング、データ・マスキングなどのその他のツールを使用することで、顧客は、既存のアプリケーションを変更する必要のない信頼できるデータ・セキュリティ・ソリューションをデプロイできます。
ネットワークの保護
Oracle Private Cloud Applianceはプライベート・クラウド環境です。 初期化中、アプライアンスのコア・ネットワーク・コンポーネントは、既存のデータセンター・ネットワーク設計と統合されます。 アプライアンス・スイッチのアップリンク・ポートは、次レベルのデータ・センター・スイッチに接続して、すべてのトラフィックをアプライアンスとの間で送受信する冗長な高速および高帯域幅の物理接続を提供します。 つまり、プライベート・クラウド環境のパースペクティブから見ると、パブリック・ネットワークはオンプレミス・ネットワークであり、インターネット・アクセスは常にデータ・センターのエッジ・ルーターを介して間接的に行われます。
このプライベート環境は、ネットワークに関してOracle Private Cloud Applianceをセキュリティ保護する場合、いくつかの結果をもたらします:
-
ラックはオンプレミスにあり、データ・センター内に設定してオンプレミス・ネットワークに直接接続します。 クラウド・リソースとオンプレミス・ネットワークが通信できるように、インターネットを介したセキュアなトンネルは必要ありません。 アクセスは、仮想クラウド・ネットワーク(VCN)とオンプレミス・ネットワークの間のゲートウェイを介して有効化されます
-
インターネット・アクセスに関しては、インバウンドまたはアウトバウンドでは、クラウド環境のリソースにインターネットに直接アクセスできません。 パブリック・クラウド環境とは異なり、VCNに対して直接インターネット接続を有効にできるゲートウェイはありません。 データ・センター内のネットワーキング・コンポーネントの構成によって、クラウド・リソースがインターネットに接続する方法と、インターネットからアクセスできるかどうかが決まります。
-
通常、このプライベート環境は、Oracle Private Cloud Appliance仮想ネットワークがパブリック・インターネットの脅威から十分に分離されていることを意味します。 ただし、このプライベート・ネットワーク内でパブリックIPアドレスを使用できます。 パブリックIPによって、リソースが存在するVCNの外部からリソースにアクセスできます。 「パブリック」とみなされるIPアドレスは、実際にはデータ・センターのプライベート範囲に含まれています。
ただし、クラウド・ネットワーク・セキュリティおよびコンピュート・インスタンスへのアクセスを制御するために実行できるステップがあります:
-
インスタンスにパブリックIPアドレスが必要ない場合は、プライベート・サブネットを使用します。
-
インスタンス上のファイアウォール・ルールを構成して、パケット・レベルでインスタンス間のトラフィックを制御します。 ただし、Oracle-Oracle Linuxを実行するイメージには、SSHトラフィックのTCPポート22でのイングレスを許可するデフォルト・ルールが自動的に含まれます。 また、Microsoft Windowsイメージには、リモート・デスクトップ・アクセス用にTCP port 3389でイングレスを許可するデフォルト・ルールが含まれています。
-
必要な接続のみを許可するようにゲートウェイおよびルート表を構成します。 これにより、オンプレミス・ネットワークや別のVCNなどの外部の宛先へのトラフィック・フローを制御できます。
-
IAMポリシーを使用して、Oracle Private Cloud Applianceインタフェースへのアクセスを制御します。 アクセスできるクラウド・リソースと、許可されるアクセスのタイプを制御できます。 たとえば、ネットワークとサブネットを設定できるユーザーや、ルート表、ネットワーク・セキュリティ・グループまたはセキュリティ・リストを更新できるユーザーを制御できます。
Oracle Private Cloud Applianceネットワーク・セキュリティの詳細は、「Oracle Private Cloud Applianceユーザーズ・ガイド」および「Oracle Private Cloud Appliance管理者ガイド」を参照してください。
ネットワーキングおよびDNS
Oracle Private Cloud Applianceネットワークには、次の3つの領域でDNSサービスが必要です:
-
「サービス・エンクレーブ」のKubernetes DNS。
-
Customer Data Center Networkの認可DNSサービス(<pca>.<domain>)。
-
「コンピュート・エンクレーブ」の認可DNSサービス(顧客テナンシのサブネットからアクセス可能) (<pca>.<domain>およびinternalpca.local)。
-
外部ゾーンの場合、「コンピュート・エンクレーブ」内の再帰的DNS。
Kubernetesは、対応するKubernetesサービスのデプロイ時にサービス・エンドポイントを使用して動的に構成されるCoreDNSを使用するDNSサービスを提供します。 他の2つのDNSサービスのいずれかまたは両方が、すでに必要なCoreDNSデプロイメントを利用できる場合があります。 最悪の場合、それぞれがCoreDNSまたは別の実装を使用して個別のDNSデプロイメントを使用できます。
ポート・マトリックス
ほとんどのファイアウォールのデフォルトのセキュリティ状態は、アクセスを拒否することです。 これは、Oracle Private Cloud Applianceラックと顧客データ・センター間で使用されるファイアウォールに適用されます。 特定のOracle Private Cloud Appliance機能が正しく動作できるようにするには、特定のIPアドレスおよび関連サービスにアクセス権を付与する必要があります。 0.0.0.0/0
などの"allow all"ルールはセキュリティの目的では広すぎるため、許可するアドレス、ポートおよびプロトコルを明示的にリストすることをお薦めします。
ソースIPアドレス | 宛先IPアドレス | ポート | プロトコル | 説明 |
---|---|---|---|---|
すべての顧客ネットワーク | SE/CE結合VIP | ICMP | タイプ0/エコー・リプライ | |
すべての顧客ネットワーク | 管理ノード | ICMP | タイプ0/エコー・リプライ | |
すべての顧客ネットワーク | オブジェクト・ストレージIP | ICMP | タイプ0/エコー・リプライ | |
すべての顧客ネットワーク | SE/CE結合VIP | ICMP | タイプ3/到達不可能 | |
すべての顧客ネットワーク | 管理ノード | ICMP | タイプ3/到達不可能 | |
すべての顧客ネットワーク | オブジェクト・ストレージIP | ICMP | タイプ3/到達不可能 | |
すべての顧客ネットワーク | SE/CE結合VIP | ICMP | タイプ8/VIPへのping | |
PCA管理者 | 管理ノード | ICMP | タイプ8/ノードへのping | |
すべての顧客ネットワーク | オブジェクト・ストレージIP | ICMP | タイプ8/VIPへのping | |
PCA管理者 | SE/CE結合VIP | 22 | TCP | アクティブ管理ノードへのSSH |
PCA管理者 | 管理ノード | 22 | TCP | 特定の管理ノードへのSSH |
初期インストールのDNS IP | SE/CE結合VIP | 53 | UDP | PCA認可ゾーン |
初期インストールのDNS IP | 管理ノード | 53 | TCP | PCA認可ゾーン |
管理ノード | 初期インストールのDNS IP | 53 | UDP | 外部DNS解決 |
管理ノード | 初期インストールのDNS IP | 53 | TCP | 外部DNS解決 |
PCA管理者 | SE/CE結合VIP | 443 | TCP | SE APIエンドポイントとSE BUI |
すべてのCEユーザー | SE/CE結合VIP | 443 | TCP | CE APIエンドポイントとCE BUI |
すべてのCEユーザー | SE/CE結合VIP | 8079 | TCP | イメージ・ダウンロード・リポジトリ |
PCA管理者 | SE/CE結合VIP | 30006 | TCP | 管理CLI |
PCA管理者 | 管理ノード | 30006 | TCP | 管理CLI |
SE/CE結合VIP | DNS再帰サーバー | 53 | UDP | DNS転送 |
SE/CE結合VIP | DNS再帰サーバー | 53 | TCP | DNS転送 |
SE/CE結合VIP | 顧客のNTPサーバー | 123 | UDP | NTP |
SE/CE結合VIP | 通常はtransport.oracle.com | 443 | TCP | ASRターゲット (https://docs.oracle.com/en/engineered-systems/private-cloud-appliance/3.0/admin-3.0.2/admin-adm-healthmonitor.html#adm-health-ASR) |
SE/CE結合VIP | Grafana通知ターゲット | 443 | TCP | Grafana通知ターゲット (https://docs.oracle.com/en/engineered-systems/private-cloud-appliance/3.0/admin-3.0.2/admin-adm-healthmonitor.html#adm-health-status) |
SE/CE結合VIP | ローカルULNミラー | 443 | TCP | PCAパッチ適用 |
SE/CE結合VIP | ローカル・イメージ・リポジトリ | 443 | TCP | カスタム・イメージのインポートfrom-object-uri |
次の表に、管理ネットワーク・トラフィックに使用される専用ポートがある場合に、構成「管理ネットワークの分離」に付与する必要があるアクセス権限を示します。 管理ネットワークの使用方法の詳細は、「Oracle Private Cloud Appliance管理者ガイド」の「ハードウェア管理」章の「管理ネットワーク情報の編集」を参照してください。
ソースIPアドレス | 宛先IPアドレス | ポート | プロトコル | 説明 |
---|---|---|---|---|
すべての顧客ネットワーク | CE VIP | ICMP | タイプ0/エコー・リプライ | |
PCA管理者 | SE VIP | ICMP | タイプ0/エコー・リプライ | |
すべての顧客ネットワーク | 管理ノード | ICMP | タイプ0/エコー・リプライ | |
すべての顧客ネットワーク | オブジェクト・ストレージIP | ICMP | タイプ0/エコー・リプライ | |
すべての顧客ネットワーク | CE VIP | ICMP | タイプ3/到達不可能 | |
PCA管理者 | SE VIP | ICMP | タイプ3/到達不可能 | |
すべての顧客ネットワーク | 管理ノード | ICMP | タイプ3/到達不可能 | |
すべての顧客ネットワーク | オブジェクト・ストレージIP | ICMP | タイプ3/到達不可能 | |
すべての顧客ネットワーク | CE VIP | ICMP | タイプ8/VIPへのping | |
PCA管理者 | SE VIP | ICMP | タイプ8/VIPへのping | |
PCA管理者 | 管理ノード | ICMP | タイプ8/ノードへのping | |
すべての顧客ネットワーク | オブジェクト・ストレージIP | ICMP | タイプ8/VIPへのping | |
PCA管理者 | SE VIP | 22 | TCP | アクティブ管理ノードへのSSH |
PCA管理者 | 管理ノード | 22 | TCP | 特定の管理ノードへのSSH |
初期インストールのDNS IP | CE VIP | 53 | UDP | PCA認可ゾーン |
初期インストールのDNS IP | CE VIP | 53 | TCP | PCA認可ゾーン |
初期インストールのAdminDNS IP | SE VIP | 53 | UDP | PCA管理ゾーン |
初期インストールのAdminDNS IP | SE VIP | 53 | TCP | PCA管理ゾーン |
管理ノード | 初期インストールのDNS IP | 53 | UDP | データ・ネットワークの外部DNS解決 |
管理ノード | 初期インストールのDNS IP | 53 | TCP | データ・ネットワークの外部DNS解決 |
管理ノード | 初期インストールのAdminDNS IP | 53 | UDP | 管理ネットワークの外部DNS解決 |
管理ノード | 初期インストールのAdminDNS IP | 53 | TCP | 管理ネットワークの外部DNS解決 |
PCA管理者 | SE VIP | 443 | TCP | SE APIエンドポイントとSE BUI |
すべてのCEユーザー | CE VIP | 443 | TCP | CE APIエンドポイントとCE BUI |
すべてのCEユーザー | CE VIP | 8079 | TCP | イメージ・ダウンロード・リポジトリ |
PCA管理者 | SE VIP | 30006 | TCP | 管理CLI |
PCA管理者 | 管理ノード | 30006 | TCP | 管理CLI |
CE VIP | DNS再帰サーバー | 53 | UDP | DNS転送 |
CE VIP | DNS再帰サーバー | 53 | TCP | DNS転送 |
SE VIP | DNS再帰サーバー | 53 | UDP | DNS転送 |
SE VIP | DNS再帰サーバー | 53 | TCP | DNS転送 |
SE VIP | 顧客のNTPサーバー | 123 | UDP | NTP |
SE VIP | 通常はtransport.oracle.com | 443 | TCP | ASRターゲット (https://docs.oracle.com/en/engineered-systems/private-cloud-appliance/3.0/admin-3.0.2/admin-adm-healthmonitor.html#adm-health-ASR) |
SE VIP | Grafana通知ターゲット | 443 | TCP | Grafana通知ターゲット (https://docs.oracle.com/en/engineered-systems/private-cloud-appliance/3.0/admin-3.0.2/admin-adm-healthmonitor.html#adm-health-monitor) |
SE VIP | ローカルULNミラー | 443 | TCP | PCAパッチ適用 |
CE VIP | ローカル・イメージ・リポジトリ | 443 | TCP | カスタム・イメージのインポートfrom-object-uri |
アカウントとパスワードの作成および保守
Oracle Private Cloud Applianceシステムの電源を初めて投入する場合は、システムを初期設定するために様々なタスクを実行する必要があります。 これらのタスクには、最初のスーパー管理者ユーザー・アカウントの定義、システムやドメイン名などのシステム・パラメータの構成、アプライアンスをデータセンター・ネットワークの一部にするための基本的なネットワーク・パラメータの構成が含まれます。
Oracle Private Cloud Applianceには3つのレイヤーがあり、これら3つのレイヤーのそれぞれが異なる方法で管理されます:
-
インフラストラクチャ - ラック・ハードウェアには、デフォルトのユーザーとパスワードが含まれています。 通常、インフラストラクチャには日常業務でアクセスする必要はありません。 インストール後、デフォルトのパスワードを更新し、安全なロケーションに保存します。 インフラストラクチャ・コンテキストでは、個々のアカウントはサポートされていません。 ほとんどのインフラストラクチャ・コンポーネントには、管理ユーザーからのサポートのみでアクセスできる、管理ユーザーおよびOracle Support Servicesのアカウントという、2人のアクセス可能なユーザーしかありません。
-
「サービス・エンクレーブ」 - インストール中に作成された管理ユーザーは、このレイヤーに適用されます。 Oracle Private Cloud Applianceの管理に役立つ追加のユーザーを「サービス・エンクレーブ」に追加できますが、実際には、操作がアプライアンス全体で行われるため、これらのユーザーはほとんどありません。
-
「コンピュート・エンクレーブ」 - 「コンピュート・エンクレーブ」のユーザーは、テナンシ内に日々のタスクがあります。 コンピュート・インスタンスの作成やクラウド・リソースのモニタリングを行っている場合があります。 管理ユーザーがテナンシを作成すると、テナンシの管理者が定義され、「コンピュート・エンクレーブ」コンソールからテナンシへのアクセスを拡張できます。
各レイヤーには、ユーザー・アカウントを保守するための様々な要件と手法があります。
インフラストラクチャ・レイヤーのパスワード・メンテナンス
インフラストラクチャ・レイヤーは日常業務ではアクセスされず、マルチユーザー・エクスペリエンスを意図していません。 インフラストラクチャの大部分は、「サービス・エンクレーブ」レイヤー、または「サービス・エンクレーブ」内で実行される個々のソフトウェア・コンポーネントによって管理されます。 ラックのインストールと構成が成功したら、すぐにデフォルトのパスワードを変更します。
更新するパスワードは次のとおりです:
-
コンピュート・ノードのパスワード
ノート:
このパスワードは、コンピュート・ノードのプロビジョニング後に更新する必要はありません。 プロビジョニングによって、コンピュート・ノードのパスワードがランダム化されます。 -
コンピュート・ノードのOracle Integrated Lights Out Manager (ILOM)パスワード
-
管理ノードのパスワード
-
管理ノードのILOMパスワード
-
リーフ・スイッチのパスワード
-
管理スイッチ・パスワード
-
スパイン・スイッチ・パスワード
-
Oracle ZFS Storage Applianceパスワード
-
Oracle ZFS Storage Appliance ILOMパスワード
ノート:
Oracle ZFS Storage Appliance ILOMパスワードの変更は、Oracle ZFS Storage Applianceを使用して管理されます。 Oracle ZFS Storage Applianceに発行されるパスワード変更は、アプライアンスとILOMパスワードの両方が相互に含まれているため、変更されます。
管理ノードには、インフラストラクチャのデフォルト・パスワードを変更する必要があるかどうかを確認するためのツールがあります。 これを実行するには:
-
インストール・チームから提供されたデフォルトの管理ユーザーおよびパスワードを使用して、管理ノードにログインします。
-
次のコマンドを実行: /var/lib/pca-foundation/scripts/healthcheck.py.
ツールの出力には、出荷時のデフォルトから変更するパスワードが表示されます。
MySQLデータベース・パスワードを除くすべてのパスワードは、管理ノードにあるpca-adminツールを使用して更新する必要があります。 様々なネイティブ・インフラストラクチャ・ツールを使用すると、「サービス・エンクレーブ」障害が発生します。 ツールを使用する必要がある理由の例として、管理ノードのパスワードがあります。 pca-adminツールを使用して管理ノードを更新すると、すべての管理ノード・パスワードが同期されます。 pca-adminツールでは、管理ノードのパスワードもサービス・アクセス可能なデータベースに格納されるため、「サービス・エンクレーブ」ツールおよびサービスでノードを管理できます。
MySQLデータベース・パスワードは、管理ノードの1つから次のコマンドを使用して更新されます: /var/lib/pca-foundation/scripts/pca_change_mysql_root_password.py
パスワードは、次の2つのロケーションに格納されます:
-
96ビット・ノンスを含むGalois Counter Mode (GCM)で256ビットAdvanced Encryption Standard (AES)暗号を使用して格納されるボールト・インスタンス。
-
インフラストラクチャ・コンポーネントのネイティブ・パスワード・ツール
パスワード・アクセス情報については、インフラストラクチャ・コンポーネント情報のドキュメントを参照してください。
インフラストラクチャ・コンポーネントのパスワード複雑性ポリシーは、次のとおりです:
-
コンピュート・ノード、管理ノードまたはスイッチの場合、長さは8文字から20文字です。 長さは、Oracle ZFS Storage ApplianceおよびILOMの8文字から16文字(注意の違い)です。
-
パスワードには、各グループの文字を含める必要があります
-
小文字(a-z)
-
大文字(A-Z)
-
数値(0-9)
-
記号(@$!#%*?&)
-
インフラストラクチャのパスワード複雑性ポリシーは変更できません。
インフラストラクチャのパスワードを更新するには
-
(ログイン後に)いずれかの管理ノードでpca-adminツールを起動
-
change password <component> <password>コマンドを使用します。 次に例を示します: change password zfs <updated_password>.
パスワード更新は、パスワード更新の正常なレスポンスが返されたあとも、完了までに短時間かかることがあります。
PCAラックの配電盤(PDU)は、ロケールによって異なります。 インフラストラクチャ・プロセスの潜在的な更新については、「Oracle Private Cloud Applianceリリース・ノート」を参照してください。
PDUパスワードはデフォルト値から変更する必要があります。 パスワードの変更については、特定のPDUタイプのハードウェアのドキュメントを参照してください。
「サービス・エンクレーブ」ユーザーとパスワードのメンテナンス
インストール時および構成時に、SuperAdmin認可グループとパスワードを持つ初期ユーザーが「サービス・エンクレーブ」に設定されています。「Oracle Private Cloud Applianceインストレーション・ガイド」の構成の章を参照してください
「サービス・エンクレーブ」は、ユーザーが資格証明を共有しないマルチユーザー環境です。 「サービス・エンクレーブ」内のアクションはアプライアンス上のすべてのテナンシに影響するため、この領域に必要なユーザーはほとんどありません。 一般的なセキュリティ・ガイドラインは次のとおりです:
-
資格証明を共有しません。
-
「サービス・エンクレーブ」管理ツールへのアクセスが必要なユーザーごとにユーザーを作成します。 この演習では、より適切な監査トラッキングと個々のニーズの管理を可能にします。
-
最小特権の規則を適用するには、その個人に最適な承認グループを選択します。
-
新しいユーザーを作成するときは、共通パスワードを使用せず、新しいユーザーにはデフォルトの初期パスワードを使用しないでください。
-
パスワードを定期的に変更します。 「サービス・エンクレーブ」には、プロアクティブなパスワード変更またはタイムアウト通知はありません。
サービス・エンクレーブには4つの重要な認可グループがあります:
-
管理者 - ユーザー管理を除くほとんどの操作に対する認可
-
モニター - 自分のプロファイルのみを管理したり、サービスエンクレーブ情報を変更せずに参照できる読取り専用ロール
-
SuperAdmin - すべての機能に対する認可。SuperAdminのみが「サービス・エンクレーブ」の新しいユーザーを作成し、既存のユーザーのロールを変更できます
-
DrAdmin - ディザスタ・リカバリを設定するための認可(このグループは、Day-0構成時のみ使用されます)
「サービス・エンクレーブ」では、認可グループのリストは静的です。 承認を変更するために既存のグループを変更することはできず、別の承認で新しいグループを作成することはできません。
「サービス・エンクレーブ」のパスワード・ポリシーは次のとおりです:
-
パスワードの最小文字数は12文字です
-
パスワードに1つ以上の大文字が含まれています
-
パスワードに1つ以上の小文字が含まれています
-
パスワードに少なくとも1つの記号(@$!#%*?&)が含まれています
-
パスワードに1つ以上の数字が含まれています
「サービス・エンクレーブ」パスワード・ポリシーは変更できません。
パスワード・ストレージはサービス・データベース内にあり、パスワード・ベース・キー導出関数2 (PBKDF2)を32文字のsaltとともに使用してパスワードをハッシュします。
SuperAdminグループのユーザーの「サービス・エンクレーブ」のユーザー・メンテナンスおよびパスワード・メンテナンスは、「サービス・エンクレーブ」管理コンソール(https://adminconsole.<domain>
)または管理CLIを使用して行われます。 MONITORまたはADMINグループのユーザーは、管理CLIを使用するか、SuperAdmin認可グループのユーザーからパスワード変更をリクエストする必要があります。
管理CLIから、コマンドを使用してパスワードを変更します:
changePassword id= <id> password= <new_password> confirmPassword= <new_password>
現在のユーザーのIDを取得するには、次のコマンドを使用します:
show UserPreference
SuperAdminグループのユーザーは、管理CLIで任意のユーザーのパスワードを変更できます。 ユーザーIDのリストは、コマンドを使用して取得できます: list user.
3.0.1ソフトウェア・バージョンのパスワード管理に関する追加ノート:
-
MONITORまたはADMINグループのユーザーは、「サービス・エンクレーブ」管理コンソールでパスワードを変更できません。
-
パスワード・リカバリ機能やパスワード・リセット機能はないため、SuperAdmin機能を持つ2番目のユーザーを作成することを強くお勧めします。
-
アカウントは、何回も無効なログイン試行でロックアウトまたは無効化されません。
「サービス・エンクレーブ」レイヤーでのアイデンティティ・プロバイダの使用の詳細は、「サービス・エンクレーブ・セキュリティ機能」を参照してください。
「コンピュート・エンクレーブ」ユーザーとパスワードのメンテナンス
「Oracle Private Cloud Applianceインストレーション・ガイド」のインストールおよび構成の直後に、デフォルトの「コンピュート・エンクレーブ」ユーザーまたはテナンシはありません。
「サービス・エンクレーブ」管理者がテナンシを作成すると、初期ユーザーが作成され、パスワードが割り当てられます。
新しいテナンシ管理者がアカウントにログインし、「コンピュート・エンクレーブ」コンソール(https://console.<domain>
)を使用してパスワードを変更します。
ログインしたら、ユーザー名が表示されるコンソールの右上にあるパスワードの変更ドロップダウンを使用します。 テナンシ管理者は、どのユーザー(自身を含む)でもリセットできない唯一のユーザー・アカウントです。 「サービス・エンクレーブ」 SuperAdminによって作成されたプライマリ・テナンシ管理者が使用できるオプションは、パスワードを安全に格納し、ログインの成功後にユーザー・インタフェースでパスワードの変更アクションを使用することです。
「コンピュート・エンクレーブ」のパスワード・ポリシーは次のとおりです:
-
パスワードの最小文字数は12文字です
-
パスワードに1つ以上の大文字が含まれています
-
パスワードに1つ以上の小文字が含まれています
-
パスワードに少なくとも1つの記号(@$!#%*?&)が含まれています
-
パスワードに1つ以上の数字が含まれています
パスワード・ポリシーは変更できません。
パスワード・ストレージはサービス・データベース内にあり、パスワード・ベース・キー導出関数2 (PBKDF2)を32文字のsaltとともに使用してパスワードをハッシュします。
テナンシ管理者は、Identity and Access Management (IAM)操作の使用を開始できるように、CLIとそのアカウントも設定します。 Oracle Private Cloud Applianceでテナンシおよびユーザーとともに使用するCLIの設定手順については、「サービス・エンクレーブでの作業」を参照してください。
すべてのテナンシには、デフォルトの管理者グループがあります。 このグループは、テナンシのすべてのリソースに対して任意のアクションを実行できます(つまり、テナントにルート・アクセスできます)。 Oracleでは、テナンシ管理者のグループはできるだけ小さく保つことをお薦めしますが、少なくとも1人のバックアップ管理者が必要です。
テナンシ管理者を管理するためのセキュリティ推奨事項の一部:
-
テナンシ管理者グループのメンバーシップを付与するセキュリティ・ポリシーを必要に応じて厳密に保持します。
-
テナンシ管理者は、MFAとともに複雑度の高いパスワードを使用し、パスワードを定期的にローテーションします。
-
アカウントの設定および構成後、Oracleでは、日常の操作にテナンシ管理者アカウントを使用しないことをお薦めします。 かわりに、権限の低いユーザーおよびグループを作成します。
-
管理者アカウントは日常業務には使用されませんが、顧客のテナンシおよび業務に影響を与える緊急シナリオに対処するために引き続き必要です。 このような緊急時に管理者アカウントを使用するためのセキュアで監査可能な「緊急時」の手順を指定します。
-
従業員が組織を離れるときにはテナンシ管理アクセス権を即座に無効化します。
-
テナンシ管理者グループ・メンバーシップは制限されているため、Oracleでは、管理者アカウントのロックアウトを妨げるセキュリティ・ポリシーを作成することをお薦めします(たとえば、テナンシ管理者が退職し、現在の従業員に管理者権限がない場合)。
テナンシのデフォルト管理者以外の「コンピュート・エンクレーブ」のユーザーは、「コンピュート・エンクレーブ」コンソールのユーザー・コンテキスト(https://adminconsole.<domain>
)を使用して、管理者グループのユーザーによってパスワードをリセットできます。
ユーザーは、CLIをインストールしてコマンドで構成している場合、自分のパスワードをリセットできます:
oci iam user ui-password create-or-reset --user-id <id>
管理者はCLIコマンドを使用して、ほかのユーザー・パスワードをリセットできます。 リセット後、管理者はリセット・パスワードをユーザーに安全に通信します。 ユーザーは、コンソールにログインしてパスワードを変更するよう求められます。
「コンピュート・エンクレーブ」およびIAMセキュリティ機能を持つアイデンティティ・プロバイダのユーザーの詳細は、「アイデンティティ・プロバイダのセキュリティ機能」を参照してください。
モニタリングおよびロギング・パスワードの保守
Oracle Private Cloud Applianceのモニタリングおよびロギング機能には、次のコンソールからアクセスします:
-
Grafana: https://grafana.<domain>
-
Prometheus: https://prometheus.<domain>
Oracle Private Cloud Appliance 3.0.2では、インフラストラクチャ・レイヤーにはGrafanaとPrometheus (admin)の両方の単一のユーザーが存在し、デフォルトのパスワードがあります。 インストールおよび構成後にこのパスワードを変更します。
適切なセキュリティを確保するには、管理ノードからPython CLIツール-python3 /usr/lib/python 3.6 /site-packages/pca_foundation/secret_service/ sauron_credential_update.py -username <username> -password <password>を実行して、管理者が新しいパスワードを設定する必要があります。
Sauronパスワード・ポリシーでは、次のパスワードが必要です:
-
12-20文字の長さにする必要があります
-
大文字、小文字および数字をそれぞれ1つ以上含める必要があります
-
記号 -_+=を含めることができます
アプライアンス・インフラストラクチャ・コンポーネントのパスワード・ルールは、次のとおりです: 最小長は8文字で、少なくとも1つの小文字(a-z)、大文字(A-Z)、数字(0-9)および記号(@$!#%*&)が含まれます。 「サービスCLI」コマンドを実行して、これらのルールに一致するパスワードを適用できますが、内部的にSauronと呼ばれるアプライアンス・クラウド・ネイティブ・モニタリングおよびアラート・フレームワークのパスワード・ポリシーに違反します。
updateSauronCredentials
コマンドを実行し、モニタリング・フレームワークで新しいパスワードを拒否すると、モニタリング・フレームワークではなく、アプライアンス・インフラストラクチャ・コンポーネントのパスワード・ルールがエラー・メッセージに説明されます。 場合によっては、「サービスCLI」によって、パスワード更新コマンドがモニタリング・フレームワークによって受け入れられなかったが成功したことが報告されます。
この問題を回避するには、アプライアンス・モニタリング・フレームワークに設定したパスワードが特定のパスワード・ポリシーに準拠していることを確認してください: 12-20文字の長さで、少なくとも1つの小文字(a-z)、大文字(A-Z)、数字(0-9)および特殊文字(-_+=)が含まれます。
Oracle Private Cloud Appliance 3.0.2のモニタリング・ツールおよびロギング・ツールには、次の制限があります:
-
ユーザーを追加できません
-
資格証明更新ツールでは、リクエストの成功または失敗に関するパスワードまたは戻り情報は確認されません
-
GrafanaおよびPrometheus画面は、無効な試行後にユーザーをロックアウトしません
次の特性が原因です:
-
複雑なパスワードの選択
-
モニタリングおよびロギングの焦点としてユーザーを指定
-
管理アカウントのパスワードを共有しない
-
パスワードを定期的に変更
-
パスワードをテナンシ管理者と共有しないでください(GrafanaおよびPrometheusにはすべてのテナンシのログが含まれているため、テナンシ間の情報漏洩のためにテナンシ管理者と共有しないでください)
失敗したパスワード・ログイン試行の表示
すべてのレイヤー(インフラストラクチャ、「サービス・エンクレーブ」および「コンピュート・エンクレーブ」)のセキュリティ・モニタリングは、Grafanaインスタンス(https://grafana.<domain>で表示できます。
セキュリティ通知を含むログを表示するには:
-
「モニタリングおよびロギング・パスワードの保守」で設定したGrafana管理ユーザーおよびパスワードを使用してGrafanaにログイン
-
探索コンテキストに移動
-
Lokiデータ・ソースを選択
そのデータ・ソースから、情報を表示するインフラストラクチャまたはソフトウェア・コンポーネントを選択します。 次のログ・ラベルを使用して、様々なコンポーネントをフィルタできます:
-
管理ノードおよびコンピュート・ノードは、{host="pcamn01"}などのhostフィルタを使用
-
Oracle ZFS Storage Appliance、{log="audit"}を使用
-
「コンピュート・エンクレーブ」、{log="api-server"}を使用
-
その他のラベルは可能です
一部のコンポーネントはこの層で監視できません:
-
スイッチ(スパイン、リーフ、管理)
-
ILOM
これらのコンポーネントに監査ログが必要な場合は、コンポーネントに直接ログインします。