AlloyDB Omni のお客様は、ワークロードがサービスから最大の価値を引き出せるように、AlloyDB Omni を構成、運用する責任があります。
| 層 | Google の責任 | お客様の責任 | |
|---|---|---|---|
| ハードウェアとホスト | 物理インフラストラクチャ | 該当する場合は、最小要件と推奨要件を提供する | 物理サーバー、VM、エッジデバイス（電源、冷却、ハードウェアなど）をプロビジョニングする。 |
| ホスト オペレーティング システム（OS） | 該当する場合は、最小要件と推奨要件を提供する | Linux カーネルを管理し、OS セキュリティ パッチを適用して、ホストノードを強化する。 | |
| Kubernetes | クラスタ管理 | 該当する場合は、最小要件と推奨要件を提供する | 業界標準のベスト プラクティスに従って、アップグレードなど、クラスタを毎日管理する。 |
| ストレージ（CSI/PV） | 該当する場合は、最小要件と推奨要件を提供する | ストレージ クラスをプロビジョニングし、基盤となるアプライアンスを管理する。AlloyDB Omni にはブロック デバイスが必要なため、ブロック デバイス クラスを選択してください。 | |
| ネットワーキング（CNI） | 該当する場合は、最小要件と推奨要件を提供する | ネットワーク層（Pod ネットワーキング、Ingress コントローラ、ロードバランサ、ノード間のファイアウォール ルールなど）をプロビジョニングして管理する。 | |
| ロールベース アクセス制御（RBAC） | AlloyDB Omni Kubernetes Operator に必要なサービス アカウント、ロール、ロール バインディングを提供する。 | これらのロールベース アクセス制御（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 上の PostgreSQL 9.x セキュリティ技術実装ガイド（STIG）コンプライアンス チェックリストをご覧ください。
| 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）によって発行されたエンド エンティティ証明書のみを信頼する。 | Operator は 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 ID と 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 を関連するユーザー アカウントにマッピングする。 | Operator は、ID に安全な SCRAM-SHA-256 パスワード認証を使用します。 |
直接パスワードでログインしない場合は、外部組織ディレクトリ ロールをデータベース ロールにマッピングする必要があります。 |
| V-233540 | データベース インストール アカウントを承認されたユーザーのみに制限する。 | コンテナは、ファイルへのアクセス許可と実行を postgres ユーザーに制限します。 |
ホストノード アクセス（SSH/Kubectl）をロックダウンして、Pod への不正なターミナル アクセスを防ぐ必要があります。 |