3.5. Red Hat OpenShift Service on AWS のプロセスおよびセキュリティーについて

Red Hat のサイト信頼性エンジニアリング (SRE) チームは、すべての ROSA クラスターコンポーネント、SRE サービス、および基礎となる AWS アカウントに関する一元的なモニターリングおよびアラートシステムを維持します。プラットフォーム監査ログは、一元化された SIEM (security information and event monitoring) システムに安全に転送されます。これにより、SRE チームに対して設定されたアラートがトリガーされる場合は手動によるレビューの対象となります。監査ログは SIEM システムに 1 年間保持されます。指定されたクラスターの監査ログは、クラスターの削除時に削除されません。

インシデントは、1 つ以上の Red Hat サービスの低下や停止をもたらすイベントです。インシデントは、お客様または CEE (Customer Experience and Engagement) のメンバーがサポートケースを通して報告されるか、一元化されたモニターリングおよびアラートシステムから直接提出されるか、 SRE チームのメンバーから直接提出される場合があります。

サービスおよびお客様への影響に応じて、インシデントは 重大度 に基づいて分類されます。

新たなインシデントを管理する際に、Red Hat では以下の一般的なワークフローを使用します。

プラットフォーム通知は、メールを使用して設定されます。一部のお客様への通知はアカウントの対応 Red Hat アカウントチーム (テクニカルアカウントマネージャーを含む) にも送信されます。

以下のアクティビティーで通知をトリガーできます。

お客様は、データの定期的なバックアップを取る責任があり、リージョン内の高可用性を確保するために、Kubernetes のベストプラクティスに従うワークロードでマルチ AZ クラスターをデプロイする必要があります。クラウドリージョン全体が利用できない場合、お客様は新しいクラスターを異なるリージョンにインストールし、バックアップデータを使用してアプリケーションを復元する必要があります。

STS を使用する ROSA クラスターで利用できる Red Hat 提供のバックアップ方法はありません。Red Hat は、RTO (Recovery Point Objective) または RTO (Recovery Time Objective) にコミットしません。

クラスター容量の評価および管理に関する責任は、Red Hat とお客様との間で共有されます。Red Hat SRE は、クラスター上のすべてのコントロールプレーンおよびインフラストラクチャーノードの容量に関する責任を負います。

Red Hat SRE はアップグレード時に、またクラスターのアラートへの対応としてクラスター容量の評価も行います。クラスターアップグレードの容量に与える影響は、アップグレードのテストプロセスの一部として評価され、容量がクラスターへの新たな追加内容の影響を受けないようにします。クラスターのアップグレード時にワーカーノードが追加され、クラスターの容量全体がアップグレードプロセス時に維持されるようにします。

Red Hat SRE チームによる容量評価は、使用状況のしきい値が一定期間超過した後のクラスターからのアラートへの対応として行われます。このアラートにより、通知がお客様に出されます。

クラスターデプロイメント、ワーカーノードのスケーリング、またはクラスターの削除などのセルフサービス機能を使用して変更を開始できます。

変更履歴は、OpenShift Cluster Manager の 概要タブ の クラスター履歴 セクションにキャプチャーされ、表示できます。変更履歴には、以下の変更のログが含まれますが、これに限定されません。

以下のコンポーネントの OpenShift Cluster Manager での変更を回避することで、メンテナンスの除外を実装できます。

Red Hat サイト信頼性エンジニアリング (SRE) は、GitOps ワークフローと完全に自動化された CI/CD パイプラインを使用して、Red Hat OpenShift Service on AWS のインフラストラクチャー、コード、および設定を管理します。このプロセスにより、Red Hat は、お客様に悪影響を与えることなく、継続的にサービスの改善を安全に導入できます。

提案されるすべての変更により、チェック時にすぐに一連の自動検証が実行されます。変更は、自動統合テストが実行されるステージング環境にデプロイされます。最後に、変更は実稼働環境にデプロイされます。各ステップは完全に自動化されます。

認可された SRE レビュー担当者は、各ステップに進む前にこれを承認する必要があります。変更を提案した個人がレビュー担当者になることはできません。すべての変更および承認は、GitOps ワークフローの一部として完全に監査可能です。

一部の変更は、機能フラグを使用して指定されたクラスターまたはお客様に対する新機能の可用性を制御することで、段階的にリリースされます。

OpenShift Container Platform ソフトウェアおよび基礎となるイミュータブルな Red Hat CoreOS (RHCOS) オペレーティングシステムイメージには、通常の z-stream アップグレードのバグおよび脆弱性のパッチが適用されます。OpenShift Container Platform ドキュメントの RHCOS アーキテクチャー を参照してください。

Red Hat はクラスターを自動的にアップグレードしません。OpenShift Cluster Manager Web コンソールを使用して、クラスターの更新を定期的に (定期的なアップグレード) または 1 回だけ (個別にアップグレード) 行うようにスケジュールできます。クラスターが重大な影響を与える CVE の影響を受ける場合にのみ、Red Hat はクラスターを新しい z-stream バージョンに強制的にアップグレードする可能性があります。

お客様は OpenShift Cluster Manager Web コンソールで、すべてのクラスターアップグレードイベントの履歴を確認できます。リリースの詳細は、ライフサイクルポリシー を参照してください。

利用可能なサブプロセスの一覧は、Red Hat カスタマーポータルの Red Hat Subprocessor List を参照してください。

SRE は、Web コンソールまたはコマンドラインツールを使用して Red Hat OpenShift Service on AWS クラスターにアクセスします。認証には、パスワードの複雑さおよびアカウントのロックアウトに関する業界標準の要件が適用されるマルチファクター認証 (MFA) が必要です。SRE は、監査可能性を確保するために個人として認証する必要があります。すべての認証試行は、セキュリティー情報およびイベント管理 (SIEM) システムに記録されます。

SRE は、暗号化された HTTP 接続を使用してプライベートクラスターにアクセスします。接続は、IP 許可リストまたはプライベートクラウドプロバイダーのリンクを使用して、セキュアな Red Hat ネットワークからのみ許可されます。

図3.1 ROSA クラスターへの SRE アクセス

SRE は、Red Hat OpenShift Service on AWS および AWS コンポーネントにアクセスする際に最小権限の原則に従います。手動による SRE アクセスには、基本的に以下の 4 つのカテゴリーがあります。

これらのアクセスタイプのそれぞれには、コンポーネントへの異なるレベルのアクセスがあります。

Red Hat の担当者は、通常の Red Hat OpenShift Service on AWS 操作では AWS アカウントにアクセスしません。緊急のトラブルシューティングが必要な場合に、SRE にはクラウドインフラストラクチャーアカウントにアクセスするための明確に定義された監査可能な手順があります。

SRE は、AWS Security Token Service (STS) を使用して確保したロールの有効期間の短い AWS アクセストークンを生成します。STS トークンへのアクセスは監査ログに記録され、個別のユーザーまでトレースできます。STS および非 STS クラスターはいずれも、SRE アクセスに AWS STS サービスを使用します。STS 以外のクラスターの場合は、BYOCAdminAccess ロールに AdministratorAccess IAM ポリシーが割り当てられ、このロールは管理に使用されます。STS クラスターの場合、ManagedOpenShift-Support-Role には ManagedOpenShift-Support-Access ポリシーが割り当てられており、このロールは管理に使用されます。

通常、Red Hat の CEE (Customer Experience and Engagement) チームは、クラスターの各部分への読み取り専用アクセスを持ちます。とくに、CEE にはコアおよび製品の namespace への制限されたアクセスがありますが、お客様の namespace へのアクセスはありません。

お客様のアクセスは、お客様によって作成される namespace、およびお客様管理者ロールによって RBAC を使用して付与されるパーミッションに限定されます。基礎となるインフラストラクチャーまたは製品 namespace へのアクセスは通常、cluster-admin アクセスなしでは許可されません。お客様のアクセスと認証の詳細は、このドキュメントの認証に関するセクションを参照してください。

新規の SRE ユーザーアクセスには、管理者の承認が必要です。分離された SRE アカウントまたは転送された SRE アカウントは、自動化されたプロセスで認可されたユーザーとして削除されます。さらに、SRE は、認可されたユーザー一覧の管理者の署名を含む、定期的なアクセスのレビューを実行します。

Red Hat は、データの機密性を判断し、収集、使用、送信、保存、処理中にデータの機密性と整合性に対する固有のリスクを特定するためにデータ分類の標準を定義し、これに従います。お客様が所有するデータは、最高レベルの機密性と処理要件を持つものとして分類されます。

Red Hat OpenShift Service on AWS (ROSA) は、AWS Key Management Service (KMS) を使用して、暗号化されたデータのキーを安全に管理します。これらのキーは、デフォルトで暗号化されるコントロールプレーン、インフラストラクチャー、およびワーカーデータボリュームに使用されます。お客様のアプリケーションの永続ボリューム (PV) は、キー管理に AWS KMS を使用します。

お客様が ROSA クラスターを削除すると、コントロールプレーンのデータボリュームや、永続ボリューム (PV) などのお客様のアプリケーションデータボリュームを含め、すべてのクラスターのデータが永久に削除されます。

Red Hat は業界標準ツールを使用して ROSA の定期的な脆弱性スキャンを実行します。特定される脆弱性は、重大度に基づくタイムラインに応じて修復されるまで追跡されます。コンプライアンス認定監査の過程で、脆弱性スキャンと修復のアクティビティーが文書化され、サードパーティーの評価者による検証が行われます。

Red Hat は、ROSA に対して定期的なペネトレーションテストを実行します。テストは、業界標準ツールやベストプラクティスを使用して独立した内部チームによって実行されます。

検出される可能性のある問題は、重大度に基づいて優先付けされます。オープンソースプロジェクトに属する問題が確認される場合は、解決に向けてコミュニティーに共有されます。

Red Hat OpenShift Service on AWS は、セキュリティーおよび管理に関する一般的な業界のベストプラクティスに従います。認定の概要を以下の表に示します。