ID およびアクセス管理

Identity and Access Management (IAM) を使用すると、 IBM Cloud アカウント内のリソースを制御できます。 リソースはリソース・グループに編成され、IAM アクセス・ポリシーを介してアカウント・ユーザーおよびサービス ID へのアクセス権限が付与されます。 職務分離の原則を採用することにより、 IBM Cloud のユーザーとサービス ID には、それぞれの役割を実行するために必要なアクセス権限のみが付与されます。 以下を参照して、 IBM Cloud IAM の初期理解を深め、職務分離を有効にするように IBM Cloud アカウントを構成してください。

• IBM Cloudでのアクセス管理
• リソースを編成してアクセス権限を割り当てるためのベスト・プラクティス
• IBM Cloud Identity and Access Managementとは

Activity Tracker

IBM Cloud Activity Tracker は、UI/CLI/API を介して IBM Cloud 内のサービスの状態を変更するアクティビティーを記録します。 Activity Tracker サービスを使用して、異常なアクティビティーや重要なアクションを調査したり、規制監査要件に準拠したりすることができます。 さらに、アクションの発生時にアラートを受け取ることができます。 収集されるイベントは、Cloud Auditing Data Federation (CADF) 標準に準拠しています。 VPC および Activity Trackerで追跡されるイベントについては、 Activity Tracker を参照してください。

フロー・ログ

IBM Cloud Flow Logs for Virtual Private Cloud (VPC) は、VPC 内のネットワーク・インターフェースとの間で送受信される Internet Protocol (IP) トラフィックに関する情報の収集、保管、および表示を可能にします。 フロー・ログは、セキュリティー・グループ・ルールを診断するために特定のトラフィックが仮想サーバー・インスタンスに到達しない理由のトラブルシューティングや、コンプライアンス規則への準拠の有効化など、いくつかのタスクに役立ちます。 詳しくは、 フロー・ログについて を参照してください。

フロー・ログは、時間枠内の 2 つの仮想ネットワーク・インターフェース・カード (vNIC) 間のネットワーク・トラフィックの要約です。 フロー・ログは、セキュリティー・グループまたはネットワーク ACL が受け入れまたは拒否するトラフィックを記述します。 フロー・ログには、伝送制御プロトコル (TCP) およびユーザー・データグラム・プロトコル (UDP) トラフィックのヘッダー情報およびペイロード統計が含まれますが、Internet Control Message Protocol (ICMP) トラフィックは含まれません。 キー・コンポーネントは以下のとおりです。

• 収集フロー・ログ・コレクターはフロー・データを収集するように構成され、コレクターは異なるスコープで構成できます。
  • VPC-特定の VPC 上のすべてのネットワーク・インターフェースのデータを収集します。
  • サブネット-特定のサブネット上のすべてのネットワーク・インターフェースのデータを収集します。
  • インスタンス-特定の仮想サーバー上のすべてのネットワーク・インターフェースのデータを収集します。
  • インターフェース-特定の仮想サーバー上の特定のネットワーク・インターフェースのデータを収集します。
• ストレージ・フロー・ログは、 IBM Cloud Object Storage (COS) バケットに保管されます。 このバケットは、フロー・ログ・コレクターのセットアップ中に構成されます。
• プレゼンテーション- IBM Cloud SQL Query は、COS 上のデータに対する IBMのサーバーレス SQL サービスであり、COS に保管されているフロー・ログに対する照会を作成するために使用されます。 詳しくは、 フロー・ログ・オブジェクトの表示 および IBM Cloud SQL Query を参照してください。

モニタリング

IBM Cloud Monitoring は、サーバーのパフォーマンスと正常性を運用面で可視化するために、 IBM Cloud アーキテクチャーの一部として組み込むことができるクラウド・ネイティブ・モニター・システムです。 IBM Cloud Monitoring サービスのインスタンスがプロビジョンされると、モニター対象の各ホストにモニター・エージェントがインストールされます。 Web UI を介して、リソースのモニター、アラートの構成、およびイベントの探索を行うことができます。

IBM Cloud Monitoringを使用して Windows システムをモニターするには、 Prometheus WMI エクスポーターを使用して、システムでメトリックの収集を実行します。 メトリックを公開するには、以下の 2 つのオプションがあります。

1. Linux システムでモニタリング・エージェントを実行し、Windows エンドポイントをリモートからスクレイプします。
2. Windows で Prometheus をクライアント・コレクターとして実行することにより、Prometheus のリモート書き込み機能を使用して Windows システムからメトリックをプッシュします。

ステップバイステップのインストールと構成については、 Windows 環境のモニターを参照してください。

ログ分析

IBM Log Analysis サービスにより、 IBM Cloudのリソースからのイベント・ログの管理が可能になります。 IBM Log Analysis は、ログをモニターするためのフィルタリング、検索、アラートの定義、およびカスタム・ビューの設計を行う機能を提供します。 サービスの概要については、 概要 を参照してください。 Log Analysis は、Windows ロギングをネイティブにサポートしません。 そのため、代わりの集中ロギング・サービスを使用する必要があります。

バックアップ

SQL Server でのバックアップとリストアは、ネイティブ統合またはサード・パーティー統合のいずれかに分類できます。

• ネイティブ-詳しくは、「 Quickstart: Backup and restore a SQL Server database 」を参照してください。 SQL Server Management Studio (SSMS) を使用して、データベースのフルバックアップを作成し、バックアップをリストアするプロセスについて説明しています。 バックアップは、 SQL Server のインストール時に構成されたバックアップ・ロケーション、またはユーザー定義のロケーション (ファイル共有など) に保管されます。 バックアップは、 SQL Server エージェント・ジョブを使用してスケジュールできます。 SQL Server の概念について詳しくは、 バックアップの概要 (SQL Server)を参照してください。
• サード・パーティー統合-使用可能なサード・パーティー統合がいくつかあります。ここでは、 IBM Spectrum Protect、Veeam、および IBM Spectrum Protect Plusの 3 つのみを説明します。
  • IBM Spectrum Protect -Data Protection for SQL を使用すると、 IBM Spectrum Protect Storage Manager サーバーへの Microsoft SQL Server データベースのオンライン・バックアップとリストアを実行できます。 IBM Spectrum Protect Storage Manager サーバーの実装については、 IBM Spectrum Protect Cloud Blueprintsを参照してください。 Data Protection for SQL のインストールについては、 ダウンロード情報: バージョン 8.1.9 IBM Spectrum Protect for Databasesを参照してください。
  • Veeam-Veeam Agent for Microsoft Windows は、 IBM Cloud VPC 仮想サーバー・インスタンスにデプロイできるデータ保護と災害復旧のソリューションです。 詳しくは、 Veeam Agent の使用を参照してください。 Veeam Agent for Microsoft Windows を Veeam Backup and Replication と共に使用することもできます。ここで、Veeam Backup and Replication は、すべての Veaam Agent の集中バックアップ・ソリューションを提供します。 詳しくは、 Veeam Backup and Replication ソフトウェアの使用を参照してください。 SQL Serverのバックアップについて詳しくは、 Microsoft SQL Serverを参照してください。
  • IBM Spectrum Protect Plus - IBM Spectrum Protect Plus は、仮想環境 vSphere または Hyper-V 用のデータ保護ソリューションであり、 IBM Cloud VPC 仮想サーバー上でホストされる SQL Serverを含む多くのアプリケーションに対してアプリケーション・データ保護を提供します。 IBM Spectrum Protect Plus は、スタンドアロン・ソリューションとして実装することも、 IBM Spectrum Protect 環境と統合して長期保管およびガバナンスのためにコピーをオフロードすることもできます。 IBM Spectrum Protect Plus は、 IBM Cloud で既存の VMware 環境に自動的にインストールできます。詳しくは、 Spectrum Protect Plus サーバー を参照してください。 IBM Spectrum Protect Plus および SQL Serverについて詳しくは、 SQL Server データのバックアップとリストアを参照してください。

IBM Cloud Security and Compliance Center

IBM Cloud Security and Compliance Center により、セキュリティーの脆弱性を特定できるため、影響を軽減し、脆弱性の問題を修正することができます。 コレクター・ホストとして機能するには、VPC に Red Hat Enterprise Linux、 CentOS、または Ubuntu 仮想サーバーの cx2-2x4 プロファイル (2 vCPU、4 GB RAM、および 4Gbps) をデプロイする必要があります。 コレクターは、Docker イメージとしてパッケージされているソフトウェア・モジュールです。

プロファイルは、内部および外部の規制に照らしてリソースを検証するために使用される、関連する目標 (セキュリティー検査) の集合です。 VPC によるセキュリティーとコンプライアンスの状況のモニター を参照してください。

スコープは、スキャンのフォーカスを特定の環境、領域、またはリソースに絞り込むために使用されます。 その後、リソースをディスカバーし、その構成を評価し、事前定義プロファイルに照らしてリソースのコンプライアンスを検証するために、スキャンがスケジュールされます。 Security and Compliance Center を参照してください。

データ暗号化

1 次ブート・ボリュームと 2 次データ・ボリュームは、 IBM管理の暗号化を使用して自動的に暗号化されますが、お客様管理の暗号化を使用して独自の暗号化を管理することもできます。 サポートされている鍵管理サービスは、Key Protect と Hyper Protect Crypto Services (HPCS) です。 詳しくは、 VPC のデータ暗号化についてを参照してください。

セキュリティー・グループ

IBM Cloud Security Groups for VPC では、仮想サーバー・インスタンスの各ネットワーク・インターフェースをその IP アドレスに基づいてフィルタリングできるようにするルールを適用できます。

• デフォルトでは、セキュリティー・グループはすべてのトラフィックを拒否します。
• ルールが追加されると、許可されるトラフィックが定義されます。
• ルールはステートフルであるため、許可されたトラフィックに対する応答としてのリバース・トラフィックは自動的に許可されます。
• セキュリティー・グループの適用範囲は単一の VPC です。
• セキュリティー・グループ内に複数の仮想サーバーがある場合でも、サーバー間のトラフィックを許可する必要があります。

詳しくは、『セキュリティー・グループの概要』を参照してください。

アクセス制御リスト

アクセス制御リスト (ACL) は、仮想サーバー・インスタンスとの間のトラフィックを制御するセキュリティー・グループではなく、VPC サブネットとの間で送受信されるすべてのトラフィックを制御します。

• ACL はステートレスであるため、インバウンド・ルールとアウトバウンド・ルールの両方を個別に明示的に指定する必要があります。
• 各 ACL は、ソース IP、ソース・ポート、宛先 IP、宛先ポート、およびプロトコルに基づく規則で構成されます。
• サブネットには常に 1 つの ACL だけを付加できますが、1 つの ACL を複数のサブネットに付加することはできます。
• ルールは順に処理されます。
• どの VPC にも、すべてのインバウンド・トラフィックおよびアウトバウンド・トラフィックを許可するデフォルトの ACL があります。

Microsoft Windows Server の保護

Center for Internet Security (CIS) ベンチマークは、システムを安全に構成するための構成ベースラインおよびベスト・プラクティスであり、1 つ以上の CIS コントロールを参照します。 CIS 制御は、NIST Cybersecurity Framework (CSF) と NIST SP 800-53、ISO 27000 シリーズの標準、PCI DSS、HIPAA など、多くの確立された標準および規制フレームワークにマップされます。 Windows OS の強化については、 Microsoft Windows Server の保護 を参照してください。MS SQL 2019 の強化については、 Microsoft SQL Server を参照してください。

Windows サーバーへのパッチ適用

IBM Cloud VPC ネットワーク上に Microsoft 更新サーバーがないため、インターネット経由で Microsoft リポジトリーにアクセスする必要があります。 これは、以下の方法で行うことができます。

• 浮動 IP を仮想サーバーに接続する方法について詳しくは、 仮想サーバー・インスタンスの外部接続に浮動 IP アドレスを使用する を参照してください。
• パブリック・ゲートウェイをサブネットに接続します。詳しくは、 サブネットの外部接続にパブリック・ゲートウェイを使用する を参照してください。
• Windows Server Update Services (WSUS) を要塞サブネット上の仮想サーバー・インスタンスにデプロイし、Microsoft への外部アクセスにパブリック・ゲートウェイを使用します。 WSUS をデプロイする方法、および WSUS サーバーを使用するようにサーバーを構成する方法を理解するには、 Windows Server Update Services のデプロイ を参照してください。

この更新トラフィックを許可するには、セキュリティー・グループまたはアクセス制御リストを更新する必要があります。

SQL Server パッチ適用

Microsoft は、SQL Server の累積パック (CU) を 2 カ月ごとにリリースします。 すべての CU には、前の累積パックが含まれています。 SQL Server 2019 の場合、CU には Microsoft SQL Serverでアクセスできます。 さらに、 SQL Server 2019 ビルド・バージョンを参照してください。

「常時オン」可用性グループでのパッチ適用プロセスの簡単な要約を以下に示します。

• 準備:
  • 現在のパッチ・レベルを判別します。
  • ターゲット・パッチ・レベル (N または N-1) を定義します。
  • パッチのリリース・ノートをお読みください。
  • ベスト・プラクティスは、実稼働環境にパッチを適用する前に、テスト環境でパッチをテストすることです。
  • プライマリー・レプリカにシステム・データベースとユーザー・データベースの最新のバックアップがあることを確認します。 フルバックアップを使用することをお勧めします。ただし、非常に大規模なデータベースの場合は、差分バックアップまたはトランザクション・ログ・バックアップのいずれかが使用可能でなければなりません。
  • セカンダリー・レプリカで、最新のシステム・データベース・バックアップを使用可能にします。
  • SQL Server Management Studio の可用性ダッシュボードを使用して、可用性グループの正常性を確認します。 可用性グループ・データベースは、同期コミットの場合は「同期化済み」状態、非同期コミット・モードの場合は「同期化中」状態でなければなりません。
• パッチ適用:
  • 1 次 MZR の 2 次レプリカ、つまり AZ2の SQL サーバーにパッチを適用します (該当する場合)。
    • SSMS を使用して、フェイルオーバー・モードを「自動」から「手動」に変更し、パッチのインストール中に自動フェイルオーバーが発生しないようにします。
    • SSMS を使用して、プライマリー・レプリカが特定のセカンダリー・レプリカにトランザクション・ブロックを送信しないように、セカンダリー・レプリカ・データベースのデータ移動を中断します。
    • RDP を介して、2 次レプリカをホストするサーバーに CU を適用します。
    • サーバーを再始動します。
    • 2 次レプリカがオンラインになったら、SSMS を使用して 2 次レプリカに接続し、以下の検証を実行します。
      • SQL サービスがオンラインであることを確認してください。
      • SQL Server のバージョン検証。
      • SQL Server のエラー・ログにエラーや警告がないか確認します。
      • パッチの適用後に、データベース整合性チェッカー (DBCC CHECKDB) を実行することもお勧めします。
      • SSMS を使用して、2 次レプリカ・データベースへのデータ移動を再開し、可用性グループ・ダッシュボードが正常に表示されるまで待ちます。
  • 該当する場合は、リカバリー MZR 内の 2 次レプリカにパッチを適用します。
    • SSMS を使用して、プライマリー・レプリカが特定のセカンダリー・レプリカにトランザクション・ブロックを送信しないように、セカンダリー・レプリカ・データベースのデータ移動を中断します。
    • RDP を介して、2 次レプリカをホストするサーバーに CU を適用します。
    • サーバーを再始動します。
    • 2 次レプリカがオンラインになったら、SSMS を使用して 2 次レプリカに接続し、以下の検証を実行します。
    • SQL サービスがオンラインであることを確認してください。
    • SQL Server のバージョン検証。
    • SQL Server のエラー・ログにエラーや警告がないか確認します。
    • パッチの適用後に、データベース整合性チェッカー (DBCC CHECKDB) を実行することもお勧めします。
    • SSMS を使用して、2 次レプリカ・データベースへのデータ移動を再開し、可用性グループ・ダッシュボードが正常に表示されるまで待ちます。
  • パッチをプライマリー・レプリカに適用します。
    • SSMS を使用して、プライマリー MZR 内のプライマリー・レプリカからセカンダリー・レプリカへの手動フェイルオーバーを実行します。 フェイルオーバーの後、プライマリー・レプリカはその状態をセカンダリー・レプリカに変更します。
    • SSMS を使用して、プライマリー・レプリカが特定のセカンダリー・レプリカにトランザクション・ブロックを送信しないように、セカンダリー・レプリカ・データベースのデータ移動を中断します。
    • RDP を介して、2 次レプリカをホストするサーバーに CU を適用します。
    • サーバーを再始動します。
    • 2 次レプリカがオンラインになったら、SSMS を使用して 2 次レプリカに接続し、以下の検証を実行します。
      • SQL サービスがオンラインであることを確認してください。
      • SQL Server のバージョン検証。
      • SQL Server のエラー・ログにエラーや警告がないか確認します。
      • パッチの適用後に、データベース整合性チェッカー (DBCC CHECKDB) を実行することもお勧めします。
      • SSMS を使用して、可用性フェイルバックを実行します。 フェイルオーバー後は、可用性グループの 1 次レプリカが 1 次ノードになります。
      • 同期データ・コミット・モードで構成された 1 次レプリカと 2 次レプリカのフェイルオーバー・モードを「自動」に変更します。
• パッチ適用後:
  • SSMS を使用して、可用性グループのフェイルオーバーとフェイルバックを実行し、SSMS 可用性ダッシュボードが正常であることを確認します。
  • すべてのレプリカのエラー・ログを確認します。
  • アプリケーション・アクセスを検証します。