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 管理 | 標準の 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）によって発行されたエンド エンティティ証明書のみを信頼する。 | オペレーターは 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）組織レベルの認証メカニズムと統合する。 | オペレーターはカスタム認証構成をサポートしています。 | 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）をロックダウンする必要があります。 |