AlloyDB Omni のお客様は、ワークロードがサービスから最大の価値を引き出せるように、AlloyDB Omni を構成、運用する責任があります。
| 層 | Google の責任 | お客様の責任 | |
|---|---|---|---|
| ハードウェアとホスト | 物理インフラストラクチャ | 該当する場合は、最小要件と推奨要件を提示する | 物理サーバー、VM、エッジデバイス（電源、冷却、ハードウェアなど）をプロビジョニングする。 |
| ホスト オペレーティング システム（OS） | 該当する場合は、最小要件と推奨要件を提示する | Linux カーネルを管理し、OS セキュリティ パッチを適用して、ホストノードを強化します。 | |
| Kubernetes | クラスタ管理 | 該当する場合は、最小要件と推奨要件を提示する | 業界標準のベスト プラクティスに沿って、アップグレードなどのクラスタの日常的な管理を行います。 |
| ストレージ（CSI/PV） | 該当する場合は、最小要件と推奨要件を提示する | ストレージ クラスをプロビジョニングし、基盤となるアプライアンスを管理します。AlloyDB Omni にはブロック デバイスが必要なため、ブロック デバイス クラスを選択してください。 | |
| ネットワーキング（CNI） | 該当する場合は、最小要件と推奨要件を提示する | ネットワーク層（Pod ネットワーキング、Ingress コントローラ、ロードバランサ、ノード間のファイアウォール ルールなど）をプロビジョニングして管理する。 | |
| ロールベース アクセス制御（RBAC） | AlloyDB Omni Kubernetes オペレーターに必要なサービス アカウント、ロール、ロール バインディングを指定します。 | これらのロールベース アクセス制御（RBAC）ルールをクラスタに適用し、内部セキュリティ ポリシーに沿っていることを確認します。AlloyDB Omni リソースにアクセスするには、追加の RBAC ロールとロール バインディングを作成します。 | |
| Secret Manager | 標準の Kubernetes Secret を読み取り、初期 postgres ユーザーなどのリソースをプロビジョニングします。 |
クラスタで Kubernetes Secret を作成、保護、ローテーションする。 | |
| 証明書の管理 | 証明書の統合には、標準の Kubernetes Secret と cert-manager を使用します。 |
cert-manager のライフサイクルをインストール、構成、管理します。 |
|
| オペレーター ソフトウェア | 開発とリリース | AlloyDB Omni Operator のロジックと CRD を開発し、コンテナ イメージ、Helm チャート、OLM バンドルを公開します。 | なし。Artifact Registry に保存されているアーティファクトをデプロイに使用できます。 |
| インストールとライフサイクル | ドキュメントとアップグレード アーティファクトを提供する。 | ||
| データベース エンジン | データベース バイナリ | カラム型エンジンや AI アクセラレーションなどの独自の最適化機能を備えた AlloyDB Omni コンテナ イメージを提供する。 | なし |
| パッチ適用と | エンジンのセキュリティ パッチ、マイナー バージョンとメジャー バージョンのアップデートをリリースする。アップグレードの手順を説明します。 | 各リリースの重要度に応じて、できるだけ早くアップグレードをスケジュールします。 | |
| ユーザー管理 |
|
|
|
| データ マネジメント | バックアップ | バックアップを管理するための BackupPlan CRD、Backup CRD、ロジックを提供します。これらは、S3 互換の統合を使用して pgBackrest で管理されます。 |
バックアップ スケジュールと保持を構成し、ローカル、S3、または Cloud Storage のターゲット ストレージ バケットをプロビジョニングします。 |
| 高可用性（HA） | 自動フェイルオーバー ロジックと修復メカニズムを提供する。 | フェイルオーバーをサポートするスタンバイ ターゲットを提供するために、十分なノードとゾーンをプロビジョニングします。 | |
| 暗号化（保存時） | 透過的データ暗号化（TDE）をサポートします。 | ストレージ レイヤの暗号化を管理して、要件を満たしていることを確認します。 | |
| 暗号化（転送中） | 内部オペレーター コンポーネントに mTLS を提供し、ユーザーとデータベース間の接続にサーバーサイド TLS を構成する。 | 安全な TLS クライアントを使用してデータベースに接続し、基盤となる証明書インフラストラクチャを管理します。 | |
| オブザーバビリティ | 指標 | Prometheus 互換のエンドポイントを使用して、内部データベースの指標を公開します。 | Prometheus、Open Telemetry、またはその他の互換性のあるソリューションとそのストレージ スタックを使用して、スクレーパをデプロイして管理します。システムの全体的な健全性をモニタリングします。 |
| ロギング | PostgreSQL ログと監査ログをコンテナ内のディスク上のファイルに書き込み、ローテーションします。 | ログコレクタ（Fluentd や Fluent Bit など）をデプロイして、ログをストレージ バックエンド（Splunk や ELK など）に送信します。ログコレクタが、推奨される最小期間である 1 か月間ログを保持するように構成されていることを確認します。 | |
| 可視化 | 標準ワークロードをモニタリングするためのサンプル指標とログ ダッシュボードを提供する。 | Grafana などの可視化ツールをデプロイして、その健全性をモニタリングします。ダッシュボードを作成し、日々の運用タスクに組み込みます。 | |
| アラート | なし | アラート パイプライン（PagerDuty 統合など）を管理する。 | |
| サポート | トラブルシューティング | ソフトウェアのバグやエンジンのエラーに関するサポートを提供します。このサポートを利用するには、ライセンス サブスクリプションが必要です。 | ドキュメントとナレッジベースを通じて初期サポートを提供します。インフラストラクチャ関連の問題をデバッグする。 |
セキュリティと FIPS コンプライアンス
データを保護するため、AlloyDB Omni は連邦情報処理標準（FIPS）140-2 または 140-3 認定の暗号モジュールを使用します。FIPS コンプライアンスは、Google とお客様の間の責任の共有です。
次の図は、AlloyDB Omni のアーキテクチャ レイヤ全体で、FIPS コンプライアンスの責任が Google とお客様の間でどのように分割されているかを示しています。
次の表に、AlloyDB Omni の FIPS の境界と責任を示します。
| FIPS 境界レイヤ | 責任範囲 | 説明 |
|---|---|---|
| FIPS 準拠のハードウェア | 顧客 | 物理ハードウェアと暗号コンポーネントは、NIST 認定を受け、FIPS 承認済みの状態で構成されている必要があります。 |
| Kubernetes ノード OS | 顧客 | ワーカーノードのホスト オペレーティング システム（RHEL など）は、FIPS モードで実行する必要があります。FIPS の状態を確認する必要があります（cat /proc/sys/crypto/fips_enabled が 1 を返す）。 |
| Kubernetes コントロール プレーン | 顧客 | kubelet などのコントロール プレーン コンポーネント、ネットワーキング プラグイン、ストレージ プラグインは、FIPS 認証取得済みの暗号モジュール（Go-BoringCrypto で構築されたものなど）を使用する必要があります。 |
| AlloyDB Omni Operator コントローラ | Google が開発し、FIPS 準拠のベースイメージ（Red Hat UBI）を基に構築。データベースが実行されているコンテナで FIPS 準拠が有効になっています。 | |
| AlloyDB Omni コンテナ イメージ | BoringSSL などの FIPS 準拠の暗号ライブラリを使用し、パスワード ハッシュ（scram-sha-256）と TLS 暗号スイートに FIPS 承認済みのアルゴリズムを適用します。 |
|
| カスタム CA の証明書 | 共有 | デジタル証明書は、鍵の強度と署名アルゴリズムに関する FIPS 規格に準拠している必要があります。証明書チェーンは、FIPS 準拠のルート CA にさかのぼる必要があります。 |
STIG の責任の共有
国防情報システム局（DISA）は、ソフトウェア、オペレーティング システム、データベースのサイバーセキュリティ標準と強化要件を確立するために、セキュリティ技術実装ガイド（STIG）を公開しています。これらのガイドでは、脆弱性やサイバー脅威からシステムを保護するための特定のセキュリティ パラメータを定義しています。
STIG ルールの完全なリストについては、AlloyDB Omni の STIG コンプライアンスをご覧ください。
STIG の要件に従って環境を強化することは、セキュリティが厳格なセクターや政府セクターで運用承認（ATO）を取得するために不可欠です。AlloyDB Omni は、デフォルトで多くのデータベース レベルのセキュリティ管理を実装していますが、完全な STIG コンプライアンスを達成するには、お客様がインフラストラクチャ レベルの設定を構成して検証する必要がある「責任の共有」となります。
次の表に、お客様による対応、検証、構成が必要なすべての STIG 脆弱性 ID を示します。詳細については、Red Hat Enterprise Linux Security Technical Implementation Guide（STIG）コンプライアンス チェックリストの PostgreSQL 9.x をご覧ください。
| STIG または SRG ID | セキュリティ管理の説明 | プラットフォームとオペレーターのデフォルトの動作 | お客様に必要な対応または設定 |
|---|---|---|---|
| V-233535 | 監査ログの失敗時にサポート スタッフにすぐにアラートを送信する。 | 標準エラー診断は、コンテナ stdout と stderr に書き込まれます。 |
お客様は、取り込みが減少したときにトリガーされるように、SIEM またはログ フォワーダーの指標（Splunk/Elastic アラートなど）を構成する必要があります。 |
| V-233599 | 監査ストレージの容量が 75% に達したときに、サポート スタッフにアラートを送信する。 | ファイル システムの指標は、標準の Prometheus エンドポイントを介して公開されます。 | お客様は、/obs/ のディスク容量が 75% を超えたときにサポートに通知するよう、Prometheus と Grafana でアラートルールを設定する必要があります。 |
| V-233610 | 監査データを別の継続的なログ機能にオフロードする。 | 監査ログは /obs/diagnostic/ ボリュームに永続的に書き込まれます。 |
お客様は、ログファイルを中央の SIEM に継続的にストリーミングするように、ログ フォワーダー（FluentBit や Vector など）を構成する必要があります。 |
| V-233603 | 公開鍵基盤（PKI）または承認された認証局（CA）によって発行されたエンド エンティティ証明書のみを信頼します。 | オペレーターは cert-manager を使用してローカル TLS 構成を構成します。 |
お客様は、信頼チェーンを確立するために、PKI ルート証明書と中間 CA 証明書をオペレーターに提供する必要があります。 |
| V-233520 | 承認された論理アクセス認可を適用する。 | 書式なしテキストのパスワードと Message-Digest アルゴリズム 5（MD5）を拒否します。SSL 経由の scram-sha-256 を許可します。 |
お客様は、接続文字列で sslmode=verify-full を使用して SCRAM-SHA-256 を使用するようにクライアントを構成する必要があります。 |
| V-233522 | ユーザーあたりの同時セッション数のしきい値を制限します。 | デフォルトのデータベース ロールには、max_connections で制限される無限の上限があります。 |
お客様は、カスタム アプリケーション ロールの接続制限（ALTER ROLE ... CONNECTION LIMIT）を明示的に変更する必要があります。 |
| V-233584 | 保存されている機密情報には、NSA 承認の暗号を使用する。 | データベース コンテナは、安全で強化された UBI9 ベースレイヤを使用します。 | お客様は、基盤となる Kubernetes ホストカーネルで FIPS 140 モードが有効になっていることを確認する必要があります。 |
| V-233515 | Active Directory（AD）および Lightweight Directory Access Protocol（LDAP）の組織レベルの認証メカニズムと統合する。 | Operator は、カスタム認証構成をサポートしています。 | お客様は、AD と LDAP の ID をデータベース クラスタ構成にマッピングする必要があります。 |
| V-233583 | ハッシュには FIPS 検証済みの暗号モジュールを使用します。 | コンテナは、ハッシュ関数にホストの OpenSSL FIPS モジュールを使用します。 | お客様は、ホスト VM ノードで FIPS モードを有効にする必要があります。 |
| V-233585 | FIPS 認証済みの暗号を使用して、未分類の情報を保護する。 | FIPS 対応の暗号を使用して通信とストレージを暗号化します。 | お客様は、ホストノードが FIPS 認証済みであることを確認する必要があります。 |
| V-233619 | すべてのオペレーションに FIPS 検証済みの暗号モジュールを使用します。 | UBI9 FIPS 対応コンテナ イメージ バイナリを適用します。 | お客様は、ホストカーネルで FIPS モードを有効にする必要があります。 |
| V-233623 | DBMS が、認定済みの OpenSSL FIPS を搭載したホストで実行されていることを確認します。 | データベース Pod は、ホストの OpenSSL FIPS 構成に依存します。 | お客様は、ホストの OpenSSL が NIST 認定の FIPS リストと一致することを確認する必要があります。 |
| V-233615 | PKI 認証された ID を関連するユーザー アカウントにマッピングします。 | オペレーターは、ID に安全な SCRAM-SHA-256 パスワード認証を使用します。 |
直接パスワード サインインを使用しない場合は、外部の組織ディレクトリのロールをデータベースのロールにマッピングする必要があります。 |
| V-233540 | データベース インストール アカウントを、承認されたユーザーのみに制限します。 | コンテナは、ファイルへのアクセス許可と実行を postgres ユーザーに制限します。 |
お客様は、Pod への不正なターミナル アクセスを防ぐために、ホストノード アクセス（SSH/Kubectl）をロックダウンする必要があります。 |