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

Red Hat Ceph Storage 5

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

概要

本書では、Ceph Storage クラスターおよびそのクライアントのデータセキュリティーと強化情報を提供します。
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO、Chris Wright のメッセージを参照してください。

第1章 はじめに

セキュリティーは重要な懸念事項であり、Red Hat Ceph Storage デプロイメントの重点を置く必要があります。データ侵害とダウンタイムはコストがかかり、管理が困難です。法律では監査とコンプライアンスプロセスに合格することが義務付けられている場合があり、プロジェクトではデータのプライバシーとセキュリティーがある程度期待されています。本書では、Red Hat Ceph Storage のセキュリティーに関する全般的な概要と、システムのセキュリティーをサポートする Red Hat の役割について説明します。

1.1. 前書き

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

1.2. Red Hat Ceph Storageの概要

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

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

  • Ceph Monitors (ceph-mon): Ceph モニターは重要な機能を提供しています。まずは、クラスターの状態に関する合意が確立され、2 番目に、OSD が稼働しているかどうかやクラスター内での履歴を維持します。3 つ目は、どのクライアントがデータの書き込みと読み取りを行うプールの一覧を提供します。最後に、クライアントと Ceph Storage Cluster デーモンの認証を提供します。
  • Ceph Manager (ceph-mgr): Ceph Manager デーモンは、Ceph OSD 全体に分散される配置グループのコピー間のピアングのステータス、配置グループの状態履歴、Ceph クラスターに関するメトリックを追跡します。また、外部監視および管理システム用のインターフェースも提供します。
  • Ceph OSD (ceph-osd): Ceph Object Storage Daemons (OSD) は、クライアントデータの保存と提供、クライアントデータのセカンダリー Ceph OSD デーモンへのレプリケート、その健全性と隣接する OSD の健全性の追跡と Ceph Monitor への報告、障害からの動的リカバリー、クラスタサイズの変更時のデータのバックフィルなどの機能を備えています。

RHCS デプロイメントはすべて、Ceph Storage クラスターまたは RADOS (再利用可能な Autonomous Distributed Object Store) にエンドユーザーデータを保存します。一般的に、エンドユーザーは Ceph Storage クラスターと直接対話しないでください。その代わりに、Ceph クライアントと対話します。Ceph Storage Cluster クライアントには、主に 3 つのクライアントがあります。

  • Ceph Object Gateway (radosgw): Ceph Object Gateway (RADOS Gateway、radosgw または rgw とも呼ばれる) は、RESTful API を備えたオブジェクトストレージサービスを提供します。Ceph Object Gateway は、クライアントの代わりに Ceph Storage クラスターまたは RADOS にデータを格納します。
  • Ceph Block Device (rbd): Ceph ブロックデバイスは、Kernel RBD (krbd) を介して Linux カーネル、または librbd を介して OpenStack といったクラウドコンピューティングソリューションに、コピーオンライト、シンプロビジョニング、およびクローン可能な仮想ブロックデバイスを提供します。
  • Ceph Filesystem (cephfs): Ceph Filesystem は、1 つ以上のメタデータサーバー (mds) で構成されており、このファイルシステムの inode の部分を Ceph Storage クラスターのオブジェクトとして格納します。Ceph ファイルシステムは、カーネルクライアント、FUSE クライアント、または OpenStack などのクラウドコンピューティングソリューション向けに libcephfs ライブラリーを介してマウントすることができます。

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

1.3. ソフトウェアのサポート

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

  • アップストリーム関係およびコミュニティーの連携を維持することで、最初からセキュリティーにフォーカスできるようにします。
  • セキュリティーおよびパフォーマンス追跡レコードに基づいてパッケージを選択して設定します。
  • (アップストリームビルドを受け入れる代わりに) 関連付けられたソースコードからバイナリーをビルドします。
  • 一連の検査および品質保証ツールを適用して、潜在的なセキュリティーの問題やリグレッションの広範なアレイを防止します。
  • リリースされたすべてのパッケージにデジタル署名し、暗号化で認証されたディストリビューションチャンネルで配布します。
  • パッチおよび更新を配信するための単一の統合メカニズムを提供します。

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

第2章 脅威および脆弱性管理

Red Hat Ceph Storage (RHCS) は通常、クラウドコンピューティングソリューションとともにデプロイされるため、Red Hat Ceph Storage のデプロイメントが大規模なデプロイメントの一連のコンポーネントの 1 つとして抽象化されていると考えると便利です。これらのデプロイメントには、通常セキュリティー上の懸念事項があります。これは本ガイドでは セキュリティーゾーン と呼ばれています。脅威のアクターとベクターは、その動機とリソースへのアクセスに基づいて分類されます。目的に応じて、各ゾーンのセキュリティー上の懸念を把握することを目的としています。

2.1. 脅威アクター

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

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

  • ネーションステートアクター: これは最も有能な敵です。国民国家の攻撃者は、ターゲットに対して莫大なリソースをもたらす可能性があります。彼らは他のどの攻撃者よりも優れた能力を持っています。人間と技術の両方で非常に厳格な管理が行われていなければ、これらの攻撃者から身を守ることは非常に困難です。
  • 深刻な組織犯罪: このクラスは、非常に有能で経済的に主導された攻撃者のグループを説明します。彼らは、社内のエクスプロイト開発とターゲット研究に資金を提供することができます。近年、大規模なサイバー犯罪企業である Russian Business Network などの組織の台頭により、サイバー攻撃がどのように商品になったかが実証されています。産業スパイは、深刻な組織犯罪グループに分類されます。
  • 非常に有能なグループ: これは、通常は商業的には資金提供されていませんが、サービスプロバイダーやクラウドオペレーターに重大な脅威を招く可能性がる「ハクティビスト」タイプの組織を指します。
  • 一人で行動するやる気のある個人: この攻撃者は、不正または悪意のある従業員、不満を持った顧客、小規模な産業スパイなど、さまざまな形で登場します。
  • 幼稚なクラッカー: この攻撃者は特定の組織をターゲットとしませんが、自動化された脆弱性スキャンと不正使用を実行します。多くの場合、これらは厄介なものにすぎませんが、これらの攻撃者の 1 人による侵害は、組織の評判に対する大きなリスクです。

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

  • セキュリティー更新: ネットワーク、ストレージ、サーバーハードウェアなど、基礎となる物理インフラストラクチャーのエンドツーエンドのセキュリティーポジションを考慮する必要があります。これらのシステムには、独自のセキュリティー強化プラクティスが必要です。Red Hat Ceph Storage のデプロイメントでは、定期的にテストしてセキュリティー更新をデプロイする計画を立てる必要があります。
  • アクセス管理: アクセス管理には、認証、認可、アカウンティングが含まれます。認証は、ユーザーアイデンティティーを検証するプロセスです。承認は、パーミッションを認証ユーザーに付与するプロセスです。アカウンティングは、ユーザーがアクションを実行するユーザーを追跡するプロセスです。ユーザーにシステムアクセスを付与する場合は、最小権限の原則 を適用し、実際に必要なシステム権限をユーザーにのみ付与します。このアプローチは、悪意のある攻撃者とシステム管理者の誤植の両方のリスクを軽減するのにも役立ちます。
  • インサイダーの管理: ロールベースのアクセス制御 (最低限必要なアクセス) を慎重に割り当て、内部インターフェースで暗号化を使用し、認証/認可セキュリティー (集中管理など) を使用することで、悪意のあるインサイダーの脅威を軽減できます。また、職務の分離や不規則な職務のローテーションなど、技術以外の追加オプションを検討することもできます。

2.2. セキュリティゾーン

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

  • パブリックセキュリティーゾーン: パブリックセキュリティーゾーンは、クラウドインフラストラクチャーの完全に信頼できない領域です。この環境は、インターネット全体として参照することも、認証局がない Red Hat OpenStack デプロイメント外部のネットワークにも言及することができます。このゾーンを経由する機密性または整合性要件があるデータはすべて、暗号化などの補正制御を使用して保護する必要があります。パブリックセキュリティーゾーンは、Ceph Storage クラスターのフロントエンドまたはクライアント側のネットワークと混同 しないようにしてください。これは RHCS の public_network と呼ばれ、パブリックセキュリティーゾーンまたは Ceph クライアントセキュリティーゾーンの一部 ではありません
  • Ceph クライアントセキュリティーゾーン: RHCS では、Ceph クライアントセキュリティーゾーンは、Ceph Object Gateway、Ceph Block Device、Ceph Filesystem、librados などの Ceph クライアントにアクセスするネットワークを指します。Ceph クライアントのセキュリティゾーンは通常、ファイアウォールの背後で、パブリックのセキュリティーゾーンから自身を分離します。ただし、Ceph クライアントは常にパブリックのセキュリティーゾーンから保護される訳ではありません。パブリックのセキュリティーゾーンに、Ceph Object Gateway の S3 および Swift API を公開することができます。
  • ストレージアクセスセキュリティーゾーン: ストレージアクセスセキュリティーゾーンは、Ceph Storage クラスターにアクセスできる Ceph クライアントを提供する内部ネットワークのことです。このドキュメントが OpenStack Platform セキュリティーおよび強化ガイドで使用されている用語と一致するように、「ストレージアクセスセキュリティゾーン」というフレーズを使用します。ストレージアクセスセキュリティーゾーンには、Ceph Storage クラスターのフロントエンドまたはクライアント側のネットワーク (RHCS の public_network と呼ばれます) が含まれます。
  • Ceph クラスターセキュリティーゾーン: Ceph クラスターセキュリティーゾーンは、レプリケーション、ハートビート、バックフィル、復旧のためのネットワーク通信で Ceph Storage クラスターの OSD デーモンを提供する内部ネットワークを指します。Ceph クラスターセキュリティーゾーンには、Ceph Storage クラスターのバックサイドネットワーク (RHCS の cluster_network と呼ばれます) が含まれます。

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

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

関連情報

  • 詳細は、『Red Hat Ceph Storage Data Security and Hardenng Guide』の「Network Communications」セクションを参照してください。

2.3. セキュリティゾーンの接続

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

場合によっては、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 つのゾーンにまたがるため、セキュリティーコントロールを適用する際に特別な考慮を指定する必要があります。

2.4. セキュリティーに最適化されたアーキテクチャー

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

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

Ceph Security Guide 476225 0818

第3章 暗号化および鍵管理

Red Hat Ceph Storage クラスターは、通常、プライベートストレージクラスターネットワークを使用する場合に、独自のネットワークセキュリティーゾーンにあります。

重要

攻撃者がパブリックネットワーク上の Ceph クライアントにアクセスした場合、セキュリティーゾーンの分離は、保護には不十分な場合があります。

ネットワークトラフィックの機密性または整合性を保証するためのセキュリティー要件があり、Red Hat Ceph Storage が暗号化とキー管理を使用する状況があります。

  • SSH
  • SSL ターミネーション
  • 転送中での暗号化
  • REST での暗号化

3.1. SSH

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

  • パスワードなしの root 権限を持つ cephadm ユーザーが存在します。
  • SSH サービスが有効になり、拡張ポート 22 が開いています。
  • cephadm ユーザーの公開 SSH キーのコピーが利用可能です。
重要

拡張機能によって cephadm ユーザーにアクセスできるユーザーには、Red Hat Ceph Storage クラスターの任意のノードで root としてコマンドを実行する権限があります。

関連情報

  • 詳細は、『Red Hat Ceph Storage Installation Guide』の「How cephadm works」セクションを参照してください。

3.2. SSL ターミネーション

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 間の接続は暗号化 されません

詳細は、「Using SSL with Civetweb」および「HAProxy/keepalived Configuration」を参照してください。

3.3. 転送中での暗号化

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

メッセンジャー v2 プロトコル

Ceph の有線プロトコルの 2 つ目のバージョンである msgr2 には、以下の新機能が含まれています。

  • 安全なモードは、ネットワークを介したすべてのデータの移動を暗号化します。
  • 認証ペイロードのカプセル化による改善。
  • 機能のアドバタイズおよびネゴシエーションの改善。

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

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

  • crc

    • cephx で接続を確立すると、強固な初期認証を提供します。
    • ビットフリップから保護する crc32c 整合性チェックを提供します。
    • 悪意のある中間者攻撃に対する保護を提供しません。
    • 盗聴者がすべての認証後のトラフィックを見るのを妨げません。
  • secure

    • cephx で接続を確立すると、強固な初期認証を提供します。
    • 認証後トラフィックをすべて完全に暗号化します。
    • 暗号化整合性チェックを提供します。

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

Ceph Object Gateway 暗号化

また、Ceph Object Gateway は S3 API を使用したお客様によって提供されるキーによる暗号化をサポートします。

重要

転送において厳密な暗号化を必要とする規制コンプライアンス標準に準拠するために、管理者はクライアント側の暗号化で Ceph Object Gateway をデプロイ する必要があります

Ceph ブロックデバイスの暗号化

システム管理者は、Ceph を Red Hat OpenStack Platform 13 暗号化のバックエンドとして統合し、RBD Cinder に dm_crypt を使用して Ceph ブロックデバイスボリュームを Ceph Storage クラスター内で有線暗号化できるようにする 必要があります

重要

転送で厳密な暗号化を必要とする規制コンプライアンス標準に準拠するために、システム管理者は、RBD Cinder に dmcrypt を使用して、Ceph ストレージクラスター内で有線暗号化を行う 必要があります

関連情報

3.3.1. メッセンジャー v2 プロトコルの有効化

Red Hat Ceph Storage 5 の新規インストールの場合、messenger v2 プロトコルの msgr2 がデフォルトで有効になっています。Red Hat Ceph Storage 4 以前のバージョンの場合、Ceph Monitors はレガシー v1 ポート 6789 にバインドします。アップグレード後に、msgr2 プロトコルを有効にして新機能を利用できます。Ceph Monitor が msgr2 プロトコルにバインドされたら、Ceph Monitor サービスを再起動した後に v2 アドレスのアドバタイズを開始します。msgr2 プロトコルのデフォルト接続モードは crc です。

Red Hat Ceph Storage クラスターを計画するときは、暗号化のオーバーヘッドを含めるために、クラスターの CPU 要件を必ず考慮してください。

重要

現在、secure なモードの使用は、Red Hat Enterprise Linux 8.2 上の CephFS や krbd など、Ceph カーネルクライアントでサポートされています。secure モードの使用は、OpenStack Nova、Glance、Cinder などの librbd を使用する Ceph クライアントでサポートされています。

前提条件

  • 実行中の Red Hat Ceph Storage 5 クラスターがあること。
  • ファイアウォールで TCP ポート 3300 を開いていること。
  • Ceph Monitor ノードへの root レベルのアクセスがあること。

手順

  1. Ceph 設定ファイル (デフォルトでは /etc/ceph/ceph.conf) を開いて編集します。
  2. [global] セクションの下に以下が新しい行に追加されます。

    ms_bind_msgr2 = true
    1. 必要に応じて、Ceph デーモン間の有線暗号化を有効にし、Ceph クライアントとデーモン間の有線暗号化を有効にするには、Ceph 設定ファイルの [global] セクションに以下のオプションを追加します。

      [global]
      ms_cluster_mode=secure
      ms_service_mode=secure
      ms_client_mode=secure
  3. 変更を Ceph 設定ファイルに保存します。
  4. 更新された Ceph 設定ファイルを Red Hat Ceph Storage クラスターのすべてのノードにコピーします。
  5. msgr2 プロトコルを有効にします。

    [root@mon ~]# ceph mon enable-msgr2
  6. 各 Ceph Monitor ノードで Ceph Monitor サービスを再起動します。

    [root@mon ~]# systemctl restart ceph-mon.target

関連情報

3.4. REST での暗号化

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

  1. Ceph Storage Cluster: Ceph Storage クラスターは、Ceph OSD の Linux Unified Key Setup または LUKS 暗号化と、それに対応するジャーナル、ライトアヘッドログ、メタデータデータベースをサポートします。このシナリオでは、クライアントが Ceph Block Device、Ceph Filesystem、または librados 上に構築されたカスタムアプリケーションであるかどうかにかかわらず、Ceph は静止状態のすべてのデータを暗号化します。
  2. Ceph Object Gateway: Ceph ストレージクラスターは、クライアントオブジェクトの暗号化をサポートしています。Ceph Object Gateway がオブジェクトを暗号化する際に、それらは Red Hat Ceph Storage クラスターとは独立して暗号化されます。また、送信されるデータは、Ceph Object Gateway と Ceph Storage Cluster の間で暗号化された形式になります。

Ceph Storage クラスターの暗号化

Ceph Storage クラスターは、Ceph OSD に保存されているデータの暗号化をサポートします。Red Hat Ceph Storage は、dmcrypt を指定して lvm で論理ボリュームを暗号化できます。つまり、ceph-volume によって呼び出される lvm は、OSD の物理ボリュームではなく論理ボリュームを暗号化し、同じ OSD キーを使用してパーティションなどの LVM 以外のデバイスを暗号化できます。論理ボリュームを暗号化することで、より多くの設定の柔軟性が可能になります。

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
...

注記

LUKS および dmcrypt は、保存データの暗号化のみに対応し、移動中のデータの暗号化には対応しません。

Ceph Object Gateway 暗号化

Ceph Object Gateway は、S3 API を使用したお客様によって提供されるキーによる暗号化をサポートします。お客様が提供する鍵を使用する場合、S3 クライアントは暗号鍵を各リクエストと共に渡して、暗号化されたデータの読み取りまたは書き込みを行います。これらのキーを管理するのは、お客様の責任です。各オブジェクトの暗号化に使用する Ceph Object Gateway の鍵を覚えておく必要があります。

関連情報

第4章 アイデンティティーおよびアクセス管理

Red Hat Ceph Storage は、以下の ID およびアクセス管理を提供します。

  • Ceph Storage クラスターのユーザーアクセス
  • Ceph Object Gateway ユーザーアクセス
  • Ceph Object Gateway LDAP/AD 認証
  • Ceph Object Gateway OpenStack Keystone 認証

4.1. Ceph Storage クラスターのユーザーアクセス

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

重要

cephx プロトコルは、転送時のデータ暗号化または保存時の暗号化には対応 していません

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

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

OSD States

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

重要

Ceph クラスターを強化するには、キーリングは、現在のユーザーおよび rootのみ 読み取り/書き込み権限を付与します。client.admin 管理ユーザーキーを含むキーリングは root ユーザーに制限する必要があります。

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

4.2. Ceph Object Gateway ユーザーアクセス

Ceph Object Gateway は、ユーザーがユーザーデータを含む S3 および Swift API にアクセスすることを認証および承認する、独自のユーザー管理を備えたRESTful API サービスを提供します。認証は以下で構成されます。

  • S3 User: S3 API のユーザーのアクセスキーおよびシークレット。
  • Swift ユーザー: Swift API のユーザー向けのアクセスキーおよびシークレットSwift ユーザーは、S3 ユーザーのサブユーザーです。S3 の「parent」ユーザーを削除すると、Swift ユーザーが削除されます。
  • 管理ユーザー: 管理 API のユーザーのアクセスキーおよびシークレット。管理ユーザーは Ceph Admin API にアクセスして、ユーザーの作成やバケットやコンテナー、およびそれらのオブジェクトへのアクセス許可などの機能を実行できるため、管理ユーザーは慎重に作成する必要があります。

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

詳細は、「User Management」および「Creating an Administrative User」を参照してください。

4.3. Ceph Object Gateway LDAP/AD 認証

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 を使用する場合は、rgw_ldap_secret = PATH_TO_SECRET_FILE シークレットファイルへのアクセスが安全であることを確認してください。

関連情報

4.4. Ceph Object Gateway OpenStack Keystone 認証

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

関連情報

第5章 インフラストラクチャーセキュリティー

本ガイドのスコープは Red Hat Ceph Storage です。ただし、適切な Red Hat Ceph Storage のセキュリティー計画では、以下の前提条件を考慮する 必要 があります。

5.1. 前提条件

5.2. 管理

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

5.3. ネットワーク通信

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

  • パブリックネットワーク
  • クラスターネットワーク

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

Network Architecture

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

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

詳細は、『設定ガイド』の「Network Configuration Reference」を参照してください。

5.4. ネットワークサービスの強化

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

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

  1. firewalld サービスを起動し、システムの起動時に実行できるようにし、実行していることを確認します。

    # systemctl enable firewalld
    # systemctl start firewalld
    # systemctl status firewalld
  2. 開いているすべてのポートのインベントリーを取得します。

    # firewall-cmd --list-all

    新規インストールでは、sources: セクションを空白にし、ポートが特別に開いていないことを示します。services セクションは、SSH サービス (およびポート 22) および dhcpv6-client が有効になっていることを示します。

    sources:
    services: ssh dhcpv6-client
  3. SELinux が実行され、Enforcing であることを確認します。

    # getenforce
    Enforcing

    SELinux が Permissive の場合は、Enforcing に設定します。

    # setenforce 1

    SELinux が実行されていない場合は有効にします。詳細は、『Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理ガイド』 を参照してください。

各 Ceph デーモンは 1 つ以上のポートを使用して、Red Hat Ceph Storage クラスターの他のデーモンと通信します。場合によっては、デフォルトのポート設定を変更することができます。通常、管理者は Ceph Object Gateway または ceph-radosgw デーモンのデフォルトのポートのみを変更します。詳細は、『Object Gateway Configuration and Administration Guide』の「Changing the CivetWeb port」を参照してください。

表5.1 Ceph ポート

ポートデーモン設定オプション

8080

ceph-radosgw

rgw_frontends

6789、3300

ceph-mon

該当なし

6800-7300

ceph-osd

ms_bind_port_min から ms_bind_port_max

6800-7300

ceph-mgr

ms_bind_port_min から ms_bind_port_max

6800

ceph-mds

該当なし

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

Ceph クライアントには、ceph-radosgwceph-mdsceph-fuselibcephfsrbdlibrbd、および 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 インストールガイド』の「Firewalls」セクションを参照してください。

5.5. レポート

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

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

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

5.6. 管理者アクションの監査

システムセキュリティーの重要な要素として、クラスター上で管理者のアクションを定期的に監査することが挙げられます。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 を実行したことを示しています。

第6章 データの保持

Red Hat Ceph Storage はユーザーデータを保存しますが、通常は間接的な方法になります。顧客データの保持には、Red Hat OpenStack Platform などのその他のアプリケーションが必要になる場合があります。

6.1. Ceph Storage Cluster

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

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

6.2. Ceph ブロックデバイス

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

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

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

6.3. Ceph Filesystem

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

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

  • メタデータ: メタデータプールは、通常 inode で構成されるメタデータサーバーのデータ(mds)を格納します。つまり、ファイルの所有権、パーミッション、作成日時、最終変更日/アクセス日、親ディレクトリーなど。
  • data: データプールはファイルデータを保存します。Ceph はファイルを 1 つまたは複数のオブジェクトとして保存し、通常はエクステントなどのファイルデータのチャンクを表すことができます。

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

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

6.4. Ceph Object Gateway

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

  • ユーザー認証情報: ユーザー認証情報は通常、ユーザー ID、ユーザーアクセスキー、およびユーザーシークレットで構成されます。また、提供された場合は、ユーザー名とメールアドレスを構成することもできます。Ceph Object Gateway は、ユーザーが明示的にシステムから削除しない限り、ユーザー認証データを保持します。
  • ユーザーデータ: ユーザーデータは通常、ユーザーまたは管理者が作成したバケットまたはコンテナーと、内部にユーザーが作成した S3 または Swift オブジェクトで構成されます。Ceph Object Gateway インターフェースは、各 S3 または Swift オブジェクトに 1 つ以上の Ceph Storage クラスターオブジェクトを作成し、対応する Ceph Storage クラスターオブジェクトをデータプールに保存します。Ceph は、Ceph Storage クラスターオブジェクトを配置グループに割り当て、クラスター全体の OSD に疑似ランダムに分散または配置します。Ceph Object Gateway は、バケットまたはインデックスに含まれるオブジェクトのインデックスも保存し、S3 バケットまたは Swift コンテナーの内容の一覧表示などのサービスを有効にします。また、マルチパートアップロードを実装する際に、Ceph Object Gateway は S3 または Swift オブジェクトの部分的なアップロードを一時的に保存する可能性があります。

    エンドユーザーは、バケットまたはコンテナー、およびそれらに含まれるオブジェクトを Ceph Object Gateway で作成、変更、および削除できます。Ceph は、S3 または Swift オブジェクトを表す各 Ceph Storage クラスターオブジェクトの CRUD 操作を処理します。

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

  • ログ: Ceph Object Gateway は、ユーザーが実行しようとしているユーザー操作と実行された操作のログも保存します。このデータは、バケットまたはコンテナー、あるいは S3 バケットまたは Swift コンテナーに存在する S3 または Swift オブジェクトを誰が作成、変更、または削除したかについてのトレーサビリティーを提供します。ユーザーがデータを削除する際、ロギング情報は影響を受けず、システム管理者によって削除されるか、期限切れのポリシーによって自動的に削除されるまでストレージが保持されます。

バケットライフサイクル

Ceph Object Gateway は、オブジェクトの有効期限を含むバケットライフサイクル機能もサポートします。General Data Protection Regulation のようなデータの保持規制により、管理者はオブジェクトの有効期限ポリシーを設定し、その他のコンプライアンス要素間でエンドユーザーに開示することが必要になる場合があります。

マルチサイト

Ceph Object Gateway は、多くの場合、マルチサイトコンテキストにデプロイされます。これにより、ユーザーは 1 つのサイトにオブジェクトを格納し、Ceph Object Gateway は、別の地理的な場所にある別のクラスターにオブジェクトのレプリカを作成します。たとえば、プライマリークラスターが失敗した場合、セカンダリークラスターは操作を再開できます。別の例では、セカンダリークラスターは、エッジネットワークやコンテンツ再配信ネットワークなど、異なる地理的な位置にある場合があります。たとえば、クライアントが最も近いクラスターにアクセスして、応答時間、スループット、およびその他のパフォーマンスの特性を改善することができます。複数のサイトのシナリオでは、管理者は各サイトがセキュリティー対策を実装することを確認する必要があります。また、複数のサイトのシナリオでデータの地理的な配布が発生する場合、管理者はデータ間の境界線上にある場合に規制上の影響について認識する必要があります。

第7章 FIPS (Federal Information Processing Standard)

Red Hat Ceph Storage は、Red Hat Enterprise Linux 7.6、Red Hat Enterprise Linux 8.1、または Red Hat Enterprise Linux 8.2 で実行する際に FIPS で検証済み暗号モジュールを使用します。

関連情報

第8章 概要

本書は、Red Hat Ceph Storage のセキュリティーに関する一般的な概要のみを提供しています。さらにヘルプが必要な場合は、Red Hat Ceph Storage コンサルティングチームにお問い合わせください。