データのセキュリティーおよび強化ガイド

本書では、Red Hat Ceph Storage のデプロイメントに cephadm を使用する Ceph Orchestrator に焦点を当てて、Red Hat Ceph Storage のセキュリティーを強化するためのアドバイスとグッドプラクティス情報を提供しています。本書の指示に従って、お使いの環境のセキュリティーを強化しますが、これらの推奨事項に従ってセキュリティーやコンプライアンスを保証しません。

Red Hat Ceph Storage (RHCS) はスケーラビリティーが高く、信頼性の高いオブジェクトストレージソリューションです。これは通常、OpenStack のようなクラウドコンピューティングソリューション (スタンドアロンストレージサービスとして、またはインターフェイスを使用したネットワーク接続ストレージ) とともにデプロイされます。

RHCS デプロイメントはすべて、通常 3 種類のデーモンで設定される Ceph Storage Cluster または RADOS (Reliable Autonomous Distributed Object Store) と呼ばれるストレージクラスターで設定されます。

RHCS デプロイメントはすべて、Ceph Storage クラスターまたは RADOS (再利用可能な Autonomous Distributed Object Store) にエンドユーザーデータを保存します。通常、ユーザーは Ceph Storage Cluster と直接対話 しません。むしろ、Ceph クライアントと対話します。

Ceph Storage Cluster クライアントには、主に 3 つのクライアントがあります。

追加のクライアントには、開発者がカスタムアプリケーションを作成して Ceph Storage クラスターと対話できる librados や、管理目的でコマンドラインインターフェイスクライアントなどがあります。

Red Hat Ceph Storage のセキュリティーの重要な側面は、セキュリティーが事前に組み込まれ、Red Hat が長期にわたってサポートするソリューションを提供することです。Red Hat が Red Hat Ceph Storage を取得する特定の手順には、以下が含まれます。

さらに、Red Hat は、製品に対して脅威と脆弱性を分析する専用のセキュリティーチームを維持し、カスタマーポータルから適切なアドバイスと更新を提供します。このチームは、ほとんどが理論上の問題である問題とは対照的に、どの問題が重要であるかを決定します。Red Hat Product Security チームは専門知識を維持し、Red Hat サブスクリプション製品に関連するアップストリームコミュニティーへの貢献をもたらします。プロセスの重要な部分である RedHat Security アドバイザリーは、脆弱性が最初に公開された日に頻繁に配布されるパッチとともに、Red Hat ソリューションに影響を与えるセキュリティーの欠陥を事前に通知します。

脅威アクターは、防御を試みる可能性のある敵のクラスを指す抽象的な方法です。アクターの能力が高いほど、攻撃の軽減と防止を成功させるために必要なセキュリティー制御が厳しくなります。セキュリティーは、要件に基づいて、利便性、防御、およびコストのバランスを取ることです。ここで説明するすべての脅威アクターに対して Red Hat Ceph Storage デプロイメントのセキュリティーを保護することができない場合があります。Red Hat Ceph Storage をデプロイする場合は、デプロイメントと使用方法のバランスを判断する必要があります。

リスク評価の一環として、保存するデータの種類やアクセス可能なリソースも考慮する必要があります。これは、特定のアクターにも影響するためです。ただし、お使いのデータがアクターにさらせない場合でも、コンピューティングリソースに引き付けられる可能性があります。

次の方法は、上記で特定されたリスクの一部を軽減するのに役立ちます。

セキュリティーゾーンは、一般的な信頼要件とシステム内で期待するユーザー、アプリケーション、サーバー、またはネットワークで設定されます。通常、これらは同じ認証と承認の要件とユーザーを共有します。これらのゾーンの定義をさらに絞り込むことはできますが、本書では 4 つの異なるセキュリティーゾーンを指しています。これら 3 つは、セキュリティーが強化された Red Hat Ceph Storage クラスターのデプロイに必要な最小限のフォーマットの 3 つです。これらのセキュリティーゾーンは、少なくとも信頼されているものから順にリスト表示されます。

これらのセキュリティーゾーンは、個別にマッピングすることも、特定の RHCS デプロイメント内で信頼の可能な領域の大部分を表すこともできます。セキュリティーゾーンは、特定の RHCS デプロイメントトポロジーにマッピングする必要があります。ゾーンとその信頼要件は、Red Hat Ceph Storage がスタンドアロン容量で動作しているか、パブリック、プライベート、またはハイブリッドクラウドを提供しているかによって異なります。

これらのセキュリティーゾーンを視覚的に表示するには、Security Optimized Architecture を参照してください。

異なる信頼レベルまたは認証要件のある複数のセキュリティーゾーンにまたがるコンポーネントは、慎重に設定する必要があります。このような接続は、ネットワークアーキテクチャーにおける弱いポイントであることが多く、接続しているゾーンの信頼レベルのセキュリティー要件を満たすように常に設定する必要があります。多くの場合、攻撃の可能性があるため、接続されたゾーンのセキュリティー制御が主要な懸念事項になります。ゾーンが出会うポイントは、攻撃者がデプロイメントのより機密性の高い部分に攻撃を移行または標的化する機会を提供します。

場合によっては、Red Hat Ceph Storage の管理者は、統合ポイントが存在するどのゾーンよりも高い基準で統合ポイントを保護することを検討したい場合があります。たとえば、他のセキュリティーゾーンに接続する理由がないため、Ceph Cluster Security Zone は他のセキュリティーゾーンから簡単に分離できます。一方、Storage Access Security Zone は、Ceph モニターノードのポート 6789 へのアクセスを提供し、Ceph OSD ノード上のポート 6800-7300 を提供する必要があります。ただし、Ceph 管理者にのみ公開される必要がある Ceph Grafana 監視情報へのアクセスを提供するため、ポート 3000 は Storage Access Security Zone のみに限定する必要があります。Ceph クライアントセキュリティーゾーンの Ceph Object Gateway は、Ceph クラスターセキュリティーゾーンのモニター (ポート 6789) および OSD (ポート 6800-7300) にアクセスし、その S3 および Swift API を HTTP ポート 80 や HTTPS ポート 443 経由などのパブリックセキュリティーゾーンに公開する場合がありますが、引き続き管理 API へのアクセスを制限しないといけない場合があります。

Red Hat Ceph Storage の設計では、セキュリティーゾーンの分離が困難になります。通常、コアサービスは少なくとも 2 つのゾーンにまたがるため、セキュリティーコントロールを適用する際に特別な考慮を指定する必要があります。

Red Hat Ceph Storage クラスターのデーモンは、通常サブネットを分離しているノードで稼働するため、RHCS クラスターのセキュリティーは比較的簡単です。

一方、Ceph ブロックデバイス (rbd)、Ceph ファイルシステム (cephfs)、Ceph オブジェクトゲートウェイ (rgw) などの Red Hat Ceph Storage クライアントは RHCS ストレージクラスターにアクセスしますが、サービスを他のクラウドコンピューティングプラットフォームに公開します。

Red Hat Ceph Storage クラスターのすべてのノードは、クラスターのデプロイの一部として SSH を使用します。これは、各ノードで以下のことを意味します。

Ceph Object Gateway は HAProxy と併用してデプロイでき、負荷分散とフェイルオーバーのために keepalived を使用することができます。オブジェクトゲートウェイ Red Hat Ceph Storage バージョン 2 および 3 は Civetweb を使用します。Civetweb の以前のバージョンは SSL をサポートしておらず、新しいバージョンは SSL をサポートしていますが、パフォーマンスに制限があります。

オブジェクトゲートウェイ Red Hat Ceph Storage バージョン 5 は Beast を使用します。Beast フロントエンド Web サーバーが OpenSSL ライブラリーを使用して Transport Layer Security (TLS) を提供するように設定できます。

HAProxy と keepalived を使用して SSL 接続を終了する場合は、HAProxy および keepalived コンポーネントは暗号化キーを使用します。

HAProxy と keepalived を使用して SSL を終端する場合、ロードバランサーと Ceph Object Gateway 間の接続は暗号化 されません。

詳細は、Configuring SSL for Beast および HAProxy and keepalived を参照してください。

Ceph のオンワイヤプロトコル msgr2 の 2 番目のバージョンには、以下の機能があります。

Ceph デーモンは、レガシー、v1 互換、および新しい v2 互換の Ceph クライアントを同じストレージクラスターに接続することができるように、複数のポートにバインドします。Ceph Monitor デーモンに接続する Ceph クライアントまたはその他の Ceph デーモンは、まず v2 プロトコルを使用しますが、可能な場合は古い v1 プロトコルが使用されます。デフォルトでは、メッセンジャープロトコル v1 と v2 の両方が有効です。新規の v2 ポートは 3300 で、レガシー v1 ポートはデフォルトで 6789 になります。

messenger v2 プロトコルには、v1 プロトコルまたは v2 プロトコルを使用するかどうかを制御する 2 つの設定オプションがあります。

同様に、使用する IPv4 アドレスと IPv6 アドレスに基づいて 2 つのオプションを制御します。

msgr2 プロトコルは、以下の 2 つの接続モードをサポートします。

デフォルトのモードは crc です。

Red Hat Ceph Storage 5 以降、メッセンジャーバージョン 2 プロトコルの導入により、ネットワーク上のすべての Ceph トラフィックの暗号化がデフォルトで有効になっています。messenger v2 の secure mode 設定は、Ceph デーモンと Ceph クライアント間の通信を暗号化するため、エンドツーエンドの暗号化を提供します。

ceph config dump コマンド、netstat -Ip | grep ceph-osd コマンドを使用して messenger v2 プロトコルの暗号化を確認するか、v2 ポートで Ceph デーモンを確認できます。

Red Hat Ceph Storage 6 以降では、messenger v2 プロトコルが圧縮機能をサポートしています。

この機能は、デフォルトでは有効になっていません。ピア間のメッセージのセキュリティーレベルが低下するため、同じメッセージを圧縮して暗号化することは推奨しません。暗号化が有効になっている場合、設定オプション ms_osd_compress_mode が true に設定されるまで、圧縮を有効にする要求は無視されます。

次の 2 つの圧縮モードをサポートしています。

メッセージの圧縮が有効になっていることを確認するには、debug_ms コマンドを実行し、接続のいくつかのデバッグエントリーを確認します。また、ceph config get コマンドを実行して、ネットワークメッセージのさまざまな設定オプションに関する詳細を取得できます。

Red Hat Ceph Storage は、いくつかのシナリオでは、残りの暗号化をサポートします。

LUKS v1 は、Linux ディストリビューション間で最も幅広いサポートを持つため、Ceph は LUKS v2 ではなく LUKS v1 を使用します。

OSD を作成する際、lvm は秘密鍵を生成し、その鍵を stdin 経由で JSON ペイロードで Ceph Monitors に安全に渡します。暗号化キーの属性名は dmcrypt_key です。

デフォルトでは、Ceph は Ceph OSD に保存されたデータを暗号化しません。システム管理者は、Ceph OSD に保存されているデータを暗号化するために dmcrypt を有効にする必要があります。Ceph OSD をストレージクラスターに追加するために Ceph Orchestrator サービス仕様ファイルを使用する場合は、ファイルに次のオプションを設定して Ceph OSD を暗号化します。

...
encrypted: true
...

Ceph クラスター内の Ceph および Ceph Object Gateway デーモンには秘密鍵があります。このキーは、クラスターへの接続とクラスターでの認証に使用されます。キーのローテーション機能を使用すると、サービスの中断を最小限に抑えて、アクティブな Ceph クラスター内のアクティブなセキュリティーキーを更新できます。

キーのローテーションは、現在の業界およびセキュリティーのコンプライアンス要件を確実に満たすのに役立ちます。

ユーザーを特定し、中間者攻撃から保護するために、Ceph は cephx 認証システムを提供し、ユーザーおよびデーモンを認証します。cephx の詳細は、Ceph ユーザー管理 を参照してください。

Cephx は共有シークレットキーを使用して認証を行います。つまり、クライアントとモニタークラスターの両方にはクライアントの秘密鍵のコピーがあります。認証プロトコルは、実際にキーを公開することなく、両方の当事者がキーのコピーを持っていることをお互いに証明できるようなものです。これは相互認証を提供します。つまり、ユーザーがシークレットキーを所有し、ユーザーにはシークレットキーのコピーがあることを確認します。

ユーザーは、Ceph クライアントを使用して Red Hat Ceph Storage クラスターデーモンと対話する個人またはアプリケーションなどのシステムアクターです。

Ceph は、デフォルトで有効になっている認証および認可で実行されます。Ceph クライアントは、通常コマンドラインを使用して、指定したユーザーの秘密鍵を含むユーザー名とキーリングを指定できます。ユーザーとキーリングが引数として提供されていない場合、Ceph は client.admin 管理ユーザーをデフォルトとして使用します。キーリングが指定されていない場合は、Ceph が Ceph 設定の keyring 設定を使用してキーリングを探します。

認証を使用するように Red Hat Ceph Storage クラスターを設定するための詳細は、Red Hat Ceph Storage 6 Configuration Guide を参照してください。具体的には、Ceph 認証設定 を参照してください。

Ceph Object Gateway は、ユーザーがユーザーデータを含む S3 および Swift API にアクセスすることを認証および承認する、独自のユーザー管理を備えた RESTful アプリケーションプログラミングインターフェイス (API) サービスを提供します。認証は以下で設定されます。

Ceph Object Gateway は、すべてのユーザー認証情報を Ceph Storage クラスタープールに保存します。名前、メールアドレス、クォータ、使用方法などのユーザーに関する追加情報を保存できます。

詳細については、ユーザー管理 および 管理ユーザーの作成を 参照してください。

Red Hat Ceph Storage は、Ceph Object Gateway ユーザーを認証するために、LDAP (Light-weight Directory Access Protocol) サーバーをサポートします。LDAP または Active Directory (AD) を使用するように設定されている場合、Ceph Object Gateway は LDAP サーバーに対して定義し、Ceph Object Gateway のユーザーを認証します。

Ceph Object Gateway は、LDAP を使用するかどうかを制御します。ただし、一度設定すると、ユーザーの認証を担当するのは LDAP サーバーです。

Ceph Object Gateway と LDAP サーバー間の通信をセキュアにするため、Red Hat は LDAP Secure または LDAPS で設定をデプロイすることを推奨します。

Red Hat Ceph Storage は、OpenStack Keystone を使用して Ceph Object Gateway Swift API ユーザーの認証をサポートします。Ceph Object Gateway は Keystone トークンを受け入れ、ユーザーを認証し、対応する Ceph Object Gateway ユーザーを作成します。Keystone がトークンを検証すると、Ceph Object Gateway はユーザーが認証されているとみなします。

Ceph Object Gateway は、認証に OpenStack Keystone を使用するかどうかを制御します。ただし、設定が完了すると、ユーザーの認証を担当するのは OpenStack Keystone サービスです。

Keystone と連携するように Ceph Object Gateway を設定するには、nss db 形式への要求の作成に Keystone が使用する OpenSSL 証明書を変換する必要があります。

Red Hat Ceph Storage クラスターの管理には、コマンドラインツールを使用する必要があります。CLI ツールには、クラスターへの管理者アクセス権限を付与するための管理者キーが必要です。デフォルトでは、Ceph は管理者キーを /etc/ceph ディレクトリーに保存します。デフォルトのファイル名は ceph.client.admin.keyring です。クラスターに対する管理者権限を持つユーザーのみがキーリングにアクセスできるよう、キーリングのセキュリティーを保護する手順を説明します。

Red Hat Ceph Storage は 2 つのネットワークを提供します。

すべての Ceph デーモンおよび Ceph クライアントでは、ストレージアクセスセキュリティーゾーン の一部であるパブリックネットワークへのアクセスが必要です。一方、OSD デーモン のみ が Ceph クラスターセキュリティーゾーン の一部であるクラスターネットワークへのアクセスを必要とします。

Ceph の設定には、public_network および cluster_network の設定が含まれます。強化の目的で、CIDR 表記を使用して IP アドレスとネットマスクを指定します。クラスターに複数のサブネットがある場合は、複数のコンマ区切りの IP アドレスおよびネットマスクエントリーを指定します。

public_network = <public-network/netmask>[,<public-network/netmask>]
cluster_network = <cluster-network/netmask>[,<cluster-network/netmask>]

詳細は、Red Hat Ceph Storage Configuration Guide の Ceph network configuration セクションを参照してください。

システム管理者は、Red Hat Enterprise Linux 8 Server に Red Hat Ceph Storage クラスターをデプロイします。SELinux はデフォルトでオンになっており、ファイアウォールは SSH サービスポート 22 以外の受信トラフィックをすべてブロックします。ただし、その他の承認されていないポートが開いたり不要なサービスが有効にならないようにするため、これが当てはまるようにする 必要 があります。

各サーバーノードで、以下を実行します。

各 Ceph デーモンは 1 つ以上のポートを使用して、Red Hat Ceph Storage クラスターの他のデーモンと通信します。場合によっては、デフォルトのポート設定を変更することができます。通常、管理者は Ceph Object Gateway または ceph-radosgw デーモンのデフォルトのポートのみを変更します。

Ceph Storage クラスターのデーモンには、ceph-mon、ceph-mgr、および ceph-osd が含まれます。これらのデーモンとそのホストは、Ceph クラスターのセキュリティーゾーンで設定されます。このゾーンは、強化目的で独自のサブネットを使用する必要があります。

Ceph クライアントには、ceph-radosgw、ceph-mds、ceph-fuse、libcephfs、rbd、librbd、および librados が含まれます。これらのデーモンとそのホストは、強化目的で独自のサブネットを使用するストレージアクセスのセキュリティーゾーンで設定されます。

Ceph Storage Cluster ゾーンのホストでは、Ceph クライアントを実行しているホストのみが Ceph Storage Cluster デーモンに接続できるようにすることを検討してください。以下に例を示します。

# firewall-cmd --zone=<zone-name> --add-rich-rule="rule family="ipv4" \
source address="<ip-address>/<netmask>" port protocol="tcp" \
port="<port-number>" accept"

<zone-name> をゾーン名に、<ipaddress> を IP アドレスに、<netmask> を CIDR 表記のサブネットマスクに、<port-number> をポート番号または範囲に置き換えます。--permanent フラグを使用してプロセスを繰り返し、再起動後も変更が維持されるようにします。以下に例を示します。

# firewall-cmd --zone=<zone-name> --add-rich-rule="rule family="ipv4" \
source address="<ip-address>/<netmask>" port protocol="tcp" \
port="<port-number>" accept" --permanent

Red Hat Ceph Storage は、基本的なシステム監視を提供し、ceph-mgr デーモンプラグイン (RESTful API、ダッシュボード、その他のプラグイン (Prometheus や Zendix など)) と共にレポートします。Ceph は、設定、設定の詳細、および統計情報を取得する collectd およびソケットを使用してこの情報を収集を取得します。

システム管理者は、デフォルトのシステム動作以外に、IP-Tables プラグインまたは ConnTrack プラグインを、オープンポートと接続を追跡するように、セキュリティー上の問題について報告するように collectd を設定することもできます。

システム管理者は、ランタイム時に設定を取得することもできます。実行時の Ceph 設定の表示 を参照してください。

システムセキュリティーの重要な要素として、クラスター上で管理者のアクションを定期的に監査することが挙げられます。Red Hat Ceph Storage は、管理者アクションの履歴を /var/log/ceph/CLUSTER_FSID/ceph.audit.log ファイルに保存します。モニターホスト上で次のコマンドを実行します。

[root@host04 ~]# cat /var/log/ceph/6c58dfb8-4342-11ee-a953-fa163e843234/ceph.audit.log

各エントリーには以下が含まれます。

以下は Ceph 監査ログの出力です。

2023-09-01T10:20:21.445990+0000 mon.host01 (mon.0) 122301 : audit [DBG] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea' cmd=[{"prefix": "config generate-minimal-conf"}]: dispatch
2023-09-01T10:20:21.446972+0000 mon.host01 (mon.0) 122302 : audit [INF] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea' cmd=[{"prefix": "auth get", "entity": "client.admin"}]: dispatch
2023-09-01T10:20:21.453790+0000 mon.host01 (mon.0) 122303 : audit [INF] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea'
2023-09-01T10:20:21.457119+0000 mon.host01 (mon.0) 122304 : audit [DBG] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea' cmd=[{"prefix": "osd tree", "states": ["destroyed"], "format": "json"}]: dispatch
2023-09-01T10:20:30.671816+0000 mon.host01 (mon.0) 122305 : audit [DBG] from='mgr.14189 10.0.210.22:0/1157748332' entity='mgr.host01.mcadea' cmd=[{"prefix": "osd blocklist ls", "format": "json"}]: dispatch

Ceph などの分散システムでは、アクションが 1 つのインスタンスで開始し、クラスター内の他のノードに伝播される可能性があります。アクションが開始すると、ログは dispatch を示します。アクションが終了すると、ログは finished したことを示します。

Ceph Storage Cluster (Reliable Autonomic Distributed Object Store または RADOS と呼ばれることもあります) は、データをオブジェクトとしてプール内に保存します。ほとんどの場合、これらのオブジェクトは Ceph Block Device イメージ、Ceph Object Gateway オブジェクト、Ceph ファイルシステムファイルなどのクライアントデータを表すアトミック単位です。ただし、librados 上に構築されたカスタムアプリケーションは、プールにバインドされ、データも保存される可能性があります。

Cephx は、オブジェクトデータを格納しているプールへのアクセスを制御します。ただし、Ceph Storage Cluster ユーザーは、通常 Ceph クライアントであり、ユーザーではありません。そのため、通常、ユーザーは Ceph Storage クラスタープールでオブジェクトを直接書き込み、読み取り、または削除する機能がありません。

Red Hat Ceph Storage の最もよく使われる Ceph Block Device インターフェイス (RADOS Block Device または RBD とも呼ばれる) は、仮想ボリューム、イメージ、コンピュートインスタンスを作成し、プール内に一連のオブジェクトとして保存します。Ceph は、これらのオブジェクトを配置グループに割り当て、クラスター全体の OSD に疑似ランダムに分散または配置します。

Ceph Block Device インターフェイスを使用するアプリケーションによっては、通常 Red Hat OpenStack Platform のユーザーがボリュームとイメージを作成、変更、および削除することができます。Ceph は、個々のオブジェクトの作成、取得、更新、および削除の操作を処理します。

ボリュームとイメージを削除すると、回復不能な方法で対応するオブジェクトを破棄します。ただし、上書きされるまで、データアーティファクトはストレージメディアに引き続き存在する可能性があります。データはバックアップアーカイブのままになる可能性があります。

Ceph File System インターフェイスは仮想ファイルシステムを作成し、プール内の一連のオブジェクトとして保存します。Ceph は、これらのオブジェクトを配置グループに割り当て、クラスター全体の OSD に疑似ランダムに分散または配置します。

通常、Ceph File System は 2 つのプールを使用します。

Ceph ファイルシステムインターフェイス (通常は Red Hat OpenStack Platform) を使用するアプリケーションに応じて、ユーザーは Ceph ファイルシステムでファイルを作成、変更、および削除できます。Ceph は、ファイルを表す個々のオブジェクトの作成、取得、更新、および削除の操作を処理します。

ファイルを削除すると、回復できない方法で対応するオブジェクトが削除されます。ただし、上書きされるまで、データアーティファクトはストレージメディアに引き続き存在する可能性があります。データはバックアップアーカイブのままになる可能性があります。

データセキュリティーおよび保持の観点から、Ceph Object Gateway インターフェイスには Ceph Block Device および Ceph Filesystem インターフェイスと比較すると、いくつかの重要な違いがあります。Ceph Object Gateway はユーザーにサービスを提供します。Ceph Object Gateway は以下を保存できます。