データベースアクセス制御¶
それぞれの OpenStack コアサービス (Compute, Identity, Networking, Block Storage) は、状態や設定に関する情報をデータベースに保存します。本章では、データベースが現在 OpenStack でどのように使用されているのかを議論します。セキュリティの考慮事項、データベースバックエンドの選択によるセキュリティへの影響についても説明します。
OpenStack データベースアクセスモデル¶
OpenStack プロジェクトの中にあるすべてのサービスは単一のデータベースにアクセスします。データベースへのテーブルの作成や行単位のアクセス制限に関する明確なポリシーは今のところありません。
OpenStack には、データベース操作の詳細な制御に関する一般的な決まりがありません。アクセス権と権限は単にノードがデータベースにアクセスするかしないかに基づいて与えられます。このシナリオでは、データベースにアクセスするノードは、DROP、INSERT、UPDATE 関数の完全な権限を持っているでしょう。
精細なアクセス制御¶
OpenStack の各サービスとそれらのプロセスはデフォルトで、共有クレデンシャルを使用してデータベースにアクセスします。これにより、データベース操作の監査および、サービスとそのプロセスからデータベースへのアクセス権の剥奪が特に難しくなります。
Nova-conductor¶
コンピュートノードは、プロジェクトのインスタンスをホストするため、OpenStack で最も信頼できないサービスです。 nova-conductor サービスは、コンピュートノードとデータベースの中継役として動作する、データベースプロキシとして処理するために導入されました。その結果について本章で後ほど議論します。
以下の事項を強く推奨します。
すべてのデータベース通信の管理ネットワークへの分離
TLS を使用したセキュア通信
OpenStack サービスのエンドポイントごとに一意なデータベースユーザーアカウントの作成 (下図)
データベースの認証とアクセス制御¶
データベースにアクセスする辺りにリスクがあるため、データベースにアクセスする必要があるノードごとに一意なデータベースユーザーアカウントを作成することを強く推奨します。この機能を実行することにより、コンプライアンスを保証するため、またはノードのセキュリティ被害にあった際に分析および監査をより良くできます。また、検知した際に被害にあったノードからデータベースへのアクセス権を削除することにより、被害にあったホストを分離できます。サービスのエンドポイントのデータベースユーザーアカウントごとにこれらを作成するとき、これらに TLS を要求するよう確実に設定することに注意してください。代わりに、セキュリティを向上させるために、データベースアカウントがユーザー名とパスワードに加えて X.509 証明書認証を使用するよう設定することを推奨します。
権限¶
データベースの作成と削除、ユーザーアカウントの作成、ユーザーの権限の更新に関する完全な権限を持つ、別々のデータベース管理者 (DBA) アカウントが作成され、保護されるべきです。これは、不注意な設定ミスを防ぎ、リスクを減らし、被害の範囲を小さくする、責任の分離を実現する簡単な方法です。
データベースユーザーアカウントは OpenStack サービスのために作成され、ノードがメンバーであるサービスに関連するデータベースだけに制限された権限を持つ各ノードのために作成されます。
SSL 通信利用のための必須ユーザーアカウント¶
設定例 #1: (MySQL)¶
GRANT ALL ON dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'NOVA_DBPASS' REQUIRE SSL;
設定例 #2: (PostgreSQL)¶
In the file pg_hba.conf:
hostssl dbname compute01 hostname md5
このコマンドは SSL 経由で通信する機能を追加するのみであり、排他的ではないことに注意してください。SSL を唯一のアクセス方法にするために、暗号化されていない通信を許可するかもしれない他のアクセス方法は無効化されるべきです。
md5 パラメーターは認証方式をハッシュ化パスワードとして定義します。以下のセクションでセキュアな認証例を提供します。
OpenStack サービスのデータベース設定¶
データベースサーバーが TLS 転送を設定されている場合、SQLAlchemy クエリーの初期接続文字列に使用する CA の情報を指定する必要があります。
MySQL への :sql_connection 文字列の例:¶
sql_connection = mysql://compute01:NOVA_DBPASS@localhost/nova?charset=utf8&ssl_ca=/etc/mysql/cacert.pem
X.509 証明書を用いた認証¶
認証に X.509 クライアント証明書を要求することにより、セキュリティを向上させられるかもしれません。この方法でデータベースに認証することにより、データベースに接続しているクライアントの ID 確認をより強力にでき、通信が確実に暗号化されます。
設定例 #1: (MySQL)¶
GRANT ALL on dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'NOVA_DBPASS' REQUIRE SUBJECT
'/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=compute01' AND ISSUER
'/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=cloud-ca';
設定例 #2: (PostgreSQL)¶
hostssl dbname compute01 hostname cert
OpenStack サービスのデータベース設定¶
お使いのデータベースサーバーが認証に X.509 証明書を要求するよう設定している場合、データベースバックエンドのために適切な SQLAlchemy クエリーパラメーターを指定する必要があります。これらのパラメーターは初期接続文字列に用いる証明書、秘密鍵、認証局の情報を指定します。
MySQL への X.509 証明書認証の :sql_connection 文字列の例:
sql_connection = mysql://compute01:NOVA_DBPASS@localhost/nova?
charset=utf8&ssl_ca = /etc/mysql/cacert.pem&ssl_cert=/etc/mysql/server-cert.pem&ssl_key=/etc/mysql/server-key.pem
Nova-conductor¶
OpenStack Compute offers a sub-service called nova-conductor which proxies database connections, with the primary purpose of having the nova compute nodes interfacing with nova-conductor to meet data persistence needs as opposed to directly communicating with the database.
Nova-conductor は RPC 経由でリクエストを受信します。そして、データベース、テーブル、データへの精細なアクセス権なしでサービスを呼び出す動作を実行します。Nova-conductor は本質的にコンピュートノードがデータベースに直接アクセスすることを抽象化します。
この抽象化は、サービスがパラメーター、ストアドプロシージャーのようなものを用いたメソッドの実行を制限し、数多くのシステムがデータベースのデータに直接アクセスしたり変更したりすることを防ぐという利点を提供します。これは、一般的なストアドプロシージャーという頻繁に批判される、データベース自体の文脈や範囲の中で、これらの手順を保存して実行することなく実現されます。
残念なことに、このソリューションはより詳細なアクセス制御とデータアクセスの監査機能を複雑にします。nova-conductor サービスは RPC 経由でリクエストを受信するため、メッセージングのセキュリティを改善する重要性を強調させます。メッセージキューにアクセスするすべてのノードは、nova-conductor により提供されるこれらの方式を実行し、データベースを効率的に変更するかもしれません。
nova-conductor は OpenStack Compute のみに適用されるので、Telemetry (ceilometer)、Networking、Block Storage のような他の OpenStack コンポーネントの動作のために、コンピュートホストから直接データベースにアクセスする必要があるかもしれないことに注意してください。
nova-conductor を無効化するために、以下を (コンピュートホストの) nova.conf ファイルに記入します。
[conductor]
use_local = true
