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

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

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

RHCS デプロイメントはすべて、Ceph Storage クラスターまたは RADOS (再利用可能な Autonomous Distributed Object Store) にエンドユーザーデータを保存します。一般的に、エンドユーザーは Ceph Storage クラスターと直接対話しないでください。その代わりに、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 がスタンドアロン容量で動作しているか、パブリック、プライベート、またはハイブリッドクラウドを提供しているかによって異なります。

これらのセキュリティーゾーンを視覚的に表示するには、「セキュリティー最適化アーキテクチャー」を参照してください。

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

場合によっては、Red Hat Ceph Storage の管理者は、統合ポイントが存在するどのゾーンよりも高い基準で統合ポイントを保護することを検討したい場合があります。たとえば、他のセキュリティーゾーンに接続する理由がないため、Ceph Cluster Security Zone は他のセキュリティーゾーンから簡単に分離できます。一方、Storage Access Security Zone は、Ceph モニターノードのポート 6789 へのアクセスを提供し、Ceph OSD ノード上のポート 6800-7300 を提供する必要があります。ただし、Ceph 管理者にのみ公開される必要がある Ceph Graphana 監視情報へのアクセスを提供するため、ポート 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 ストレージクラスターにアクセスしますが、サービスを他のクラウドコンピューティングプラットフォームに公開します。

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

詳細は、「sudo アクセスを持つ Ansible User の作成」および「Ansible のパスワードなし SSH の有効化」を参照してください。

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

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

詳細は、「Civetweb で SSL を使用」および「HAProxy/keepalived 設定」を参照してください。

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

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

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

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

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

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

OSD の作成時に、lvm は秘密鍵を生成し、stdin (標準入力) を介して JSON ペイロードでその鍵を Ceph モニターにセキュアに渡します。暗号化キーの属性名は dmcrypt_key です。

デフォルトでは、Ceph は OSD に保存されているデータを暗号化しません。システム管理者は、Ceph Ansible で dmcrypt を有効にする必要があります。group_vars/osds.yml ファイルで dmcrypt オプションを設定する方法は、『Red Hat Ceph Storage インストールガイド』の「OSD Ansible 設定」を参照してください。

詳細は、『Red Hat Ceph Storage 開発者ガイド』の「S3 API サーバー側暗号化」を参照してください。

ユーザーを特定し、中間者攻撃から保護するために、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 4 の『設定ガイド』を参照してください。具体的には、『CephX 設定リファレンス』を参照してください。

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 を使用するように設定されている場合、Ceph Object Gateway は LDAP サーバーに対して定義し、Ceph Object Gateway のユーザーを認証します。

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

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

詳細は、「LDAP/AD を使用する Ceph Object Gateway ガイド」を参照してください。

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 証明書を変換する必要があります。

詳細は、「Keystone を使用した Ceph Object Gateway ユーザーの認証」を参照してください。

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

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

各 Ceph デーモンは 1 つ以上のポートを使用して、Red Hat Ceph Storage クラスターの他のデーモンと通信します。場合によっては、デフォルトのポート設定を変更することができます。通常、管理者は Ceph Object Gateway または ceph-radosgw デーモンのデフォルトのポートのみを変更します。『オブジェクトゲートウェイの設定および管理ガイド』のChanging the CivetWeb portを参照してください。

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 インストールガイド』の「ファイアウォール」セクションを参照してください。

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

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

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

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

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

たとえば、システム管理者は nodown フラグを設定および設定解除できます。監査ログでは、以下のようになります。

2018-08-13 21:50:28.723876 mon.reesi003 mon.2 172.21.2.203:6789/0 2404194 : audit [INF] from='client.? 172.21.6.108:0/4077431892' entity='client.admin' cmd=[{"prefix": "osd set", "key": "nodown"}]: dispatch
2018-08-13 21:50:28.727176 mon.reesi001 mon.0 172.21.2.201:6789/0 2097902 : audit [INF] from='client.348389421 -' entity='client.admin' cmd=[{"prefix": "osd set", "key": "nodown"}]: dispatch
2018-08-13 21:50:28.872992 mon.reesi001 mon.0 172.21.2.201:6789/0 2097904 : audit [INF] from='client.348389421 -' entity='client.admin' cmd='[{"prefix": "osd set", "key": "nodown"}]': finished
2018-08-13 21:50:31.197036 mon.mira070 mon.5 172.21.6.108:6789/0 413980 : audit [INF] from='client.? 172.21.6.108:0/675792299' entity='client.admin' cmd=[{"prefix": "osd unset", "key": "nodown"}]: dispatch
2018-08-13 21:50:31.252225 mon.reesi001 mon.0 172.21.2.201:6789/0 2097906 : audit [INF] from='client.347227865 -' entity='client.admin' cmd=[{"prefix": "osd unset", "key": "nodown"}]: dispatch
2018-08-13 21:50:31.887555 mon.reesi001 mon.0 172.21.2.201:6789/0 2097909 : audit [INF] from='client.347227865 -' entity='client.admin' cmd='[{"prefix": "osd unset", "key": "nodown"}]': finished

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

前述の例では、entity='client.admin' は、ユーザーが admin ユーザーであることを示しています。cmd=[{"prefix": "osd set", "key": "nodown"}] コマンドは、管理ユーザーが ceph osd set nodown を実行したことを示しています。

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 は、各オブジェクトの CRUD 操作を処理します。

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

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

通常、Ceph ファイルシステムは 2 つのプールを使用します。

Ceph Filesystem インターフェースを使用するアプリケーションによっては、通常は Red Hat OpenStack Platform のユーザーが Ceph ファイルシステム内でファイルを作成、変更、および削除する可能性があります。Ceph は、ファイルを表す各オブジェクトの CRUD 操作を処理します。

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

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