クラウド プラットフォームの運用および保守仕様 - パート 1

1. 運用と保守の目的

情報システムの構築は、長期にわたる、複雑で大規模なシステムエンジニアリングプロジェクトです。プロジェクトのメンテナンスは、プロジェクト全体の実装において重要な部分です。その重要な位置付けにより、当社は厳格な姿勢を堅持し、科学的管理を実施し、運用保守情報のセキュリティ管理を強化し、コンピュータ情報技術リスクを防止し、ネットワークと情報システムのセキュリティと安定した運用を確保し、要求を満たす保守作業を提供し、ユーザー満足度の定期的な追跡を実施して、以下の運用保守サービス目標が達成されることを確保する必要があります：すべての保守作業の合格率、システムとデータの日常テスト作業が基準を満たしていること。このプロジェクトの運用保守サービスの範囲は、主にこの情報構築プロジェクトを対象としており、日常的な保守、定期検査、システムの最適化、機能の保守、プロジェクトの変更などが含まれます。これらの管理仕様と標準は特別に策定されています。

II.基本規定

2.1 適用範囲

この規制は、クラウドプラットフォームシステムの運用・保守管理、セキュリティ管理、権限管理、コスト管理、変更管理などに適用されます。

2.2 基本定義

クラウド プラットフォームの運用と保守とは、クラウド コンピューティング プラットフォームを管理および保守するプロセスを指します。クラウド コンピューティング プラットフォームは、サーバー、ストレージ、ネットワーク、アプリケーションなどのコンピューティング リソースをインターネット経由でユーザーに提供する、インターネット ベースのコンピューティング サービス モデルです。クラウド プラットフォームの運用と保守には、クラウド プラットフォームの高可用性、安定性、セキュリティを確保するために、クラウド コンピューティング プラットフォームのハードウェア、ソフトウェア、ネットワーク、セキュリティの監視、保守、最適化、アップグレードが含まれます。

インターネット技術の発展に伴い、クラウド コンピューティング プラットフォームは企業の IT アーキテクチャ変革の重要な部分となっています。クラウド プラットフォームの運用と保守の重要性はますます高まっています。クラウド プラットフォームの運用と保守の主な責任には、以下の内容が含まれますが、これらに限定されません。

インフラストラクチャのメンテナンス: サーバー、ストレージ サービス、ネットワーク サービスなどを含むクラウド コンピューティング プラットフォームのインフラストラクチャを監視、保守、更新します。

ネットワークメンテナンス: ネットワークトポロジ、ルーティング、スイッチングなど、クラウドコンピューティングプラットフォームのネットワークを監視、保守、最適化します。ネットワーク障害によりサービスが利用できなくなる可能性があるため、ネットワークメンテナンスもクラウドプラットフォームの運用と保守で注意を払う必要がある側面です。

セキュリティ保守: ファイアウォール、侵入検知、脆弱性スキャンなど、クラウド コンピューティング プラットフォームのセキュリティを監視、保守、強化します。ネットワーク セキュリティは、クラウド プラットフォームの運用と保守において最も重要な側面の 1 つです。クラウド プラットフォームのセキュリティを確保することによってのみ、ユーザーは安心して使用できるようになります。

バックアップとリカバリ: クラウド リソースのバックアップとリカバリは、ビジネス継続性の確保、データの信頼性の向上、バックアップ管理の簡素化、リカバリ速度の向上、バックアップ コストの削減、データ保護コンプライアンスの確保において重要な役割を果たします。

コスト管理: クラウド コスト予算を策定し、クラウド コスト戦略を策定し、クラウド リソースの構成を最適化し、コスト管理を適切に行い、クラウド監視テクノロジを使用して、あらゆる段階でクラウド リソース コスト管理を合理的に実装します。企業が経費を合理的に計画し、リソースの利用率を向上させ、リソースの無駄を削減できるように支援し、それによってより効果的なビジネスサポートと経済的利益を実現します。 。

クラウド プラットフォームの運用と保守を効果的に管理することで、クラウド コンピューティング プラットフォームの効率的で安定した安全な運用が保証され、ユーザーの満足度と信頼が向上します。さらに、クラウド プラットフォームの運用と保守は、企業の IT コストの削減、IT リソースの利用率の向上、企業のビジネス革新と開発の促進にも役立ちます。

III.責任

4. クラウド運用保守管理仕様

4.1 運用・保守担当者の基本原則

4.1.1 遵守すべき操作および保守のルール

すべての運用および保守サービス担当者は、常に以下のガイドラインを遵守し、心に留めておく必要があります。

まず、オンライン システムを操作するときは敬意を払う必要があります。

第二に、サービスが正式に開始される前に、完全な監視と警報のカバー範囲が完了し、警報の有効性が確認されなければなりません。

3 番目に、オンライン アーキテクチャの調整は、最初に評価し、次にテストし、最後に調整するというプロセスに従う必要があります。

4 番目に、オンライン システムの設定を変更する前に、まずバックアップし、確認してから、最後に操作する必要があります。

5 番目に、あらゆるオンライン出版業務はロールバックに備える必要があります。

6 番目に、重要なシステムはバックアップし、詳細なリカバリ操作ドキュメントを作成し、バックアップの有効性チェックを定期的に実行する必要があります。

7 番目に、ホスト リソースのリサイクル/削除は繰り返し確認する必要があり、最初にシャットダウンし、少なくとも 1 日間保持してからリサイクルする必要があります。

8番目に、権限の回復は繰り返し確認する必要があります。原則として、非アクティブ化操作のみを実行し、必要がない限り削除操作は実行しないでください。

9 番目に、データ テーブルを更新/削除するには、まずそれが正しいことを選択して確認してから、更新を実行する必要があります。

10. IP アドレスを外部に公開するホストの場合、ポート セキュリティ制限を追加し、ポートの最小開放の原則に従い、有効性チェックを実行する必要があります。

4.1.2 運用と保守の鉄則

運用保守の鉄則は運用保守要員の最も基本的な資質であり、違反者は処罰される。

まず、顧客データは厳重に機密扱いされ、いかなる形でも開示、再販、または使用されることはありません。

第二に、顧客から利益を受け取ったり要求したりしてはなりません。

3番目に、顧客の違法行為を会社または経営陣に速やかに報告します。

第四に、法律や規則に違反する行為を行ってはなりません。

4.2 クラウドリソース使用仕様

4.2.1 VPC使用仕様

4.2.1.1 VPCの概要

仮想プライベート クラウド (VPC) は、クラウド プラットフォーム上でユーザーがカスタマイズした、論理的に分離されたネットワーク スペースです。ユーザーは、クラウド サーバー、クラウド データベース、負荷分散、およびその他のリソース用に論理的に分離されたユーザー定義のネットワーク スペースを構築して、ユーザーのクラウド リソースのセキュリティを向上させ、さまざまなアプリケーション シナリオのニーズを満たすことができます。

プライベート ネットワーク VPC には、プライベート ネットワーク セグメント、サブネット/スイッチ、ルーターの 3 つのコア コンポーネントがあります。

プライベート ネットワークとスイッチを作成するときは、プライベート ネットワークで使用されるプライベート ネットワーク セグメントを CIDR アドレス ブロックの形式で指定する必要があります。

スイッチ/サブネットは、プライベート ネットワークを構成する基本的なネットワーク デバイスであり、さまざまなクラウド リソースを接続するために使用されます。プライベート ネットワークを作成した後、スイッチを作成してプライベート ネットワークを 1 つ以上のサブネットに分割できます。同じプライベート ネットワーク内の異なるサブネットはデフォルトで相互に通信でき、異なるプライベート ネットワーク (同じリージョン内にあるかどうかに関係なく) はデフォルトで分離されます。ユーザーは、異なる可用性ゾーンのスイッチにアプリケーションを展開して、アプリケーションの可用性を向上させることができます。

· ルーターはプライベート ネットワークのハブです。プライベートネットワークにおける重要な機能コンポーネントとして、プライベートネットワーク内のさまざまなスイッチを接続することができ、プライベートネットワークと他のネットワークを接続するゲートウェイデバイスでもあります。各プライベート ネットワークが正常に作成されると、システムは自動的にルーターを作成します。各ルータは少なくとも 1 つのルーティング テーブルに関連付けられています。

4.2.1.2 VPC作成仕様

クラウド環境での VPC の作成には、事前にネットワーク エンジニアとのコミュニケーション、関連情報の確認、関連プロセスの承認の提出が必要です。次の仕様に従った VPC を作成します。

4.2.1.3 スイッチ/サブネット作成仕様

クラウド環境でのスイッチの作成には、事前にネットワークエンジニアとのコミュニケーションと関連情報の確認、および関連プロセスの承認の提出が必要です。スイッチを作成する際の注意:

スイッチの命名規則: 部門-ビジネスタイプ-エリア-アベイラビリティゾーン

ビジネスタイプ: アプリケーション、ポータル、データベース

Alibaba CloudはアベイラビリティゾーンEとFを推奨し、Tencent Cloudはアベイラビリティゾーン4と5を推奨しています。

高可用性ゾーンが必要かどうかを事前に確認する

以下の情報を明確にし、ネットワーク エンジニアに提供する必要があります。

4.2.2 ElasticパブリックIPの使用仕様

Elastic IP (EIP) は、独立して購入・保有できる、特定のリージョンに固定されたパブリック IP アドレスです。クラウド サーバー、プライベート ネットワーク負荷分散、NAT ゲートウェイ、エラスティック ネットワーク カード、高可用性仮想 IP などのクラウド リソースにバインドして、パブリック ネットワークにアクセスしたり、パブリック ネットワークからアクセスされたりする機能を提供できます。また、クラウド リソースのライフサイクルから切り離して独立して運用することもできます。また、さまざまな課金モードも提供しており、ユーザーはビジネス特性に応じて柔軟に選択して、パブリックネットワークのコストを削減できます。

EIP は NAT IP であり、実際にはクラウド プラットフォームのパブリック ネットワーク ゲートウェイ上に配置され、NAT を介してバインドされたクラウド リソースにマッピングされます。 EIP がクラウド リソースにバインドされると、クラウド リソースは EIP を介してパブリック ネットワークと通信できるようになります。

エラスティック パブリック ネットワーク IP を使用するには、会社の内部リソース アプリケーション作業指示プロセスを経る必要があり、それに合格すると、ネットワーク エンジニアが作成と構成を支援します。

※運用保守仕様により、Elastic Public IP をクラウド サーバー インスタンスに直接バインドすることはできませんのでご了承ください。 NAT ゲートウェイの DNAT 機能と SNAT 機能は、「ポート マッピングまたは IP マッピングを介してパブリック NAT ゲートウェイ上のパブリック IP をクラウド サーバー インスタンスに使用し、クラウド サーバー インスタンスが外部にパブリック ネットワーク アクセス サービスを提供できるようにする」機能と「VPC 内のパブリック IP を持たないクラウド サーバー インスタンスがインターネットにアクセスするためのプロキシ サービスを提供する」という 2 つの機能を実装するために使用する必要があります。

4.2.3 NATゲートウェイの使用仕様

NAT ゲートウェイは、NAT プロキシ (SNAT および DNAT) 機能を提供し、プライベート ネットワーク (VPC) 内のリソースに対して安全で高性能なインターネット アクセス サービスを提供できるネットワーク アドレス変換サービスです。

SNAT 機能は、VPC 内のパブリック IP を持たないクラウド サーバー インスタンスがインターネットにアクセスするためのプロキシ サービスを提供し、パブリック IP を持たないクラウド サーバー インスタンスがインターネットにアクセスできるようにします。

DNAT 機能は、ポート マッピングまたは IP マッピングを通じてパブリック NAT ゲートウェイ上のパブリック IP をクラウド サーバー インスタンスにマッピングし、クラウド サーバー インスタンスが外部にパブリック ネットワーク アクセス サービスを提供できるようにします。

NAT ゲートウェイを使用するには、会社の内部リソース アプリケーション作業指示プロセスを経る必要があり、それに合格すると、ネットワーク エンジニアが作成と構成を支援します。

実際の状況に基づいて、NAT ゲートウェイを複数のプロジェクトで共有できるかどうかを評価できます。

4.2.4 リソースグループ/タグの使用仕様

4.2.4.1 リソースグループ機能

リソース グループは、Alibaba Cloud アカウントの下でリソースをグループ化するメカニズムです。リソース グループは、使用状況、権限、所有権、その他のディメンションに基づいてユーザーが所有するクラウド リソースをグループ化し、企業内の複数のユーザーとプロジェクトの階層的なリソース管理を実現します。クラウド リソースは 1 つのリソース グループにのみ属することができ、リソース グループに参加してもクラウド リソース間の関係は変わりません。

適用シナリオは主に次の2つです。

まず、目的の異なるクラウド リソースを異なるリソース グループに追加して、個別に管理します。たとえば、運用環境のインスタンスとテスト環境のインスタンスを、それぞれ運用環境とテスト環境という 2 つのリソース グループに配置できます。製品をテストする場合は、実稼働環境のインスタンスの誤操作を避けるために、テスト環境リソース グループ内のインスタンスのみを操作することをお勧めします。製品を起動する必要がある場合は、運用環境のリソース グループ内のインスタンスを選択して操作します。

次に、リソース グループごとに完全に独立した管理者を設定し、リソース グループ内でユーザーと権限の管理を実装します。たとえば、社内のさまざまな部門で使用されるインスタンスを複数のリソース グループに配置し、対応する管理者を設定して、部門ごとにインスタンスを管理することができます。

4.2.4.2 タグ機能

タグは、Tencent Cloud と Alibaba Cloud が提供するクラウド リソース管理ツールです。ユーザーは、異なる次元から同じ特性を持つクラウド リソースを分類、検索、集約できるため、クラウド リソースを簡単に管理できます。

タグは、タグ キーとタグ値の 2 つの部分で構成されます。ユーザーはタグを作成し、クラウド リソースにバインドできます。タグキーは複数のタグ値に対応でき、タグキーとタグ値のペアは複数のクラウド リソースにバインドできます。

タグの主な適用シナリオは 3 つあります。

1 つは、タグを使用してクラウド リソースを管理することです。タグを使用してクラウド上の既存のリソースにマークを付け、これらのリソースの分類された管理を実装できます。タグ コンソールまたはタグ API を使用して、リージョン、タイプ、タグに基づいてリソースをクエリすることもできます。表示するリソースはリストに表示されます。

2 つ目は、タグを使用してリソースへのアクセスを制御することです。タグはアクセス管理と組み合わせて使用​​できます。タグ認証により、異なるサブユーザーは異なるクラウド リソースへのアクセスと操作の権限を持つことができます。

3つ目は、アカウント分割にタグを使用することです。組織またはビジネスのディメンション (部門、プロジェクト チーム、地域など) に基づいてリソースのタグを計画し、クラウドが提供するアカウント分割タグと請求詳細機能を組み合わせて、コスト共有管理を実装できます。

タグでサポートされるクラウド リソース:

タグをサポートする Alibaba Cloud 製品:

https://help.aliyun.com/document_detail/171455.html?spm=5176.21213303.J_6704733920.9.737953c9G4p1vf&scm=20140722.S_help@@%E6%96%87%E6%A1%A3@@17 1455._.ID_help@@%E6%96%87%E6%A1%A3@@171455-RL_%E6%94%AF%E6%8C%81%E6%A0%8 7%E7%AD%BE%E7%9A%84%E4%BA%A7%E5%93%81-LOC_main-OR_ser-V_2-RK_rerank-P0_1

Tencent Cloud は次の製品をサポートしています。

https://cloud.tencent.com/document/product/651/30727

4.3 権限管理

クラウド上の権限は、多くの場合、アクセス管理またはアクセス制御を通じて管理され、Alibaba Cloud ではアクセス制御 RAM (リソース アクセス管理) と呼ばれます。これは、ユーザー ID とリソースのアクセス権を管理するために Alibaba Cloud が提供するサービスです。 Tencent Cloud では、Cloud Access Management (CAM) と呼ばれ、Tencent Cloud が提供する Web サービスです。これは主に、ユーザーが Tencent Cloud アカウントの下にあるリソースへのアクセス権を安全に管理できるようにするために使用されます。

クラウド プラットフォーム アカウントを登録すると、生成されるアカウントはマスター アカウントとなり、マスター アカウントの下にあるすべてのクラウド リソースの管理権限を持ちます。自分のアカウントのクラウド リソースの管理を他のユーザーに手伝ってもらう必要がある場合は、アクセス制御 (RAM)/アクセス管理 (CAM) を通じてユーザー (グループ) を作成、管理、破棄し、アイデンティティ管理とポリシー管理を使用して他のユーザーの Alibaba Cloud/Tencent Cloud リソースの使用権限を制御できます。

アクセス制御 (RAM)/アクセス管理 (CAM) 機能により、アクセス ID と権限を統一的に管理できます。

サブユーザーを一元管理し、各サブユーザーとそのログインパスワードまたはアクセスキーを管理し、多要素認証 (MFA) デバイスをサブユーザーにバインドします。

サブユーザーのアクセス権を集中管理し、各サブユーザーのリソースへのアクセス権を制御する

サブユーザーのリソースアクセス方法を集中管理し、サブユーザーが指定された時間とネットワーク環境で安全なチャネルを通じて特定のクラウドリソースにアクセスできるようにします。

メイン アカウント管理者は、多くの場合、アクセス権に基づいてユーザーを次の 3 つのカテゴリに分類します: 特別ユーザー (またはシステム管理者)。一般ユーザー: システム管理者は、実際のニーズに基づいて操作権限を割り当てます。監査ユーザー: システムとネットワークのセキュリティ制御とリソース使用状況の監査を担当します。

4.3.1 ユーザーのジョブの説明

· 特別ユーザー: 実稼働環境におけるさまざまなオペレーティングシステム、ネットワークシステム、ハードウェア機器、アプリケーションソフトウェアの管理と保守を担当します。

一般ユーザー: 日常業務、監視、その他関連業務を担当します。

監査ユーザー: 運用システムに関連する監査作業を担当します。

4.3.2 ユーザー権限の原則

最小権限の原則に従う

企業は、各ロールのタスクと責任を評価し、必要な権限のみを付与する必要があります。ユーザーアカウントの認証範囲を必要最小限の範囲に制限することで、アカウント攻撃や不正アクセスのリスクを軽減し、アカウント管理の高度化と制御性を向上させることができます。

使用ポリシーの制限

ポリシー制限を使用してアカウントのセキュリティをさらに強化し、リソースへのアクセスを許可されたユーザーのみがアクセスできるようにすることができます。ポリシー制限により、管理者は、アクセス時間、許可された IP アドレス範囲、許可された操作の種類などを制限するなど、必要に応じてユーザー アクセスを安全に制限できます。また、特定の操作を実行できるユーザー (データの読み取りのみ可能で書き込みはできないなど) を制限することもできます。

ユーザー管理、権限管理、リソース管理を分離

ユーザー、権限、リソースを個別に管理することは、多くの場合「権限の分離」モデルと呼ばれ、セキュリティ分野では非常に一般的な方法です。主な考え方は、セキュリティ制御を強化するために、ユーザー、権限、リソースを個別に管理することです。

このモデルでは、ユーザー管理、権限管理、リソース管理が異なる役割または組織単位に割り当てられ、より詳細で効果的な管理と制御が保証されます。具体的には、以下のような対策が考えられます。

ユーザー管理: ユーザー アカウントの作成、変更、削除、ユーザー グループとロールの管理などを担当します。ユーザー管理の主なタスクは、各アカウントに一意の識別子が付与され、各アカウントが特定のタスクまたはワークロードに集中していることを確認することです。これにより、アカウントのセキュリティが確保され、アカウントへの適切なアクセスが制御されます。

権限管理: ユーザーのアクセス権を管理するために、ロールと権限の定義、付与、取り消しを担当します。権限管理の主なタスクは、各ユーザーが必要なリソースにのみアクセスできるようにし、不正アクセスやデータ漏洩を防ぐことです。

リソース管理: リソースの作成、変更、削除、および必要なメンテナンスと保護サービスの提供を担当します。リソース管理の主なタスクは、適切なリソース構成とアクセス制御を確保し、異常なアクティビティやセキュリティ上の問題がないかリソースを監視することです。

ユーザー管理、権限管理、リソース管理を分離することで、アカウントのセキュリティとデータの機密性をより適切に保護できます。さらに、各機能領域に特定の管理者を割り当てて、アカウント アクセスとリソースの使用状況をより適切に監視することもできます。

マスターアカウントと高リスクのサブユーザーに対して多要素認証（MFA）を有効にする

多要素認証 (MFA) は、ユーザー パスワードや携帯電話の SMS 認証など、ログイン プロセス中に 2 つ以上の認証要素の入力をユーザーに要求することで、アカウント アクセスのセキュリティを強化する方法です。高リスクの権限を持つマスター アカウントとサブユーザーの場合、MFA を有効にすると、アカウントの保護レベルがさらに向上します。

MFA を有効にする理由は、パスワードだけでは十分に安全でない場合があるためです。たとえば、パスワードが漏洩したり推測されたりした場合、ハッカーはそのパスワードを使用してユーザーのアカウントにログインできますが、ユーザーのアカウントを完全に制御することはできません。 MFA を有効にすると、潜在的に悪意のあるログイン試行を検出し、アカウントへのアクセスのセキュリティ レベルを向上させることができます。これらの認証要素は通常、動的に生成された暗号化キーまたはその他の特別なデバイスです。

通常、マスター アカウントと高リスクのサブユーザーに対して MFA を有効にすることは非常に重要です。これらの 2 つのアカウントには最高の権限アクセスがあるためです。ハッカーは通常、メイン アカウントとサブ アカウントの制御権を獲得し、アプリケーションとデータへの完全なアクセスを取得できれば満足します。ただし、MFA を有効にすると、セキュリティの層が追加され、攻撃者がアカウントにアクセスするには、2 つ以上の認証要素の情報を同時に盗んだり推測したりする必要が生じます。

すべてのユーザーのパスワードの強度とログイン制限を設定する

コンソールのパスワードの強度とログイン制限を設定すると、管理者は悪意のある攻撃や不適切な操作を防ぎ、アカウントのセキュリティを向上させることができます。

パスワードは 8 文字以上で、大文字、小文字、数字、記号など、さまざまな文字タイプを含める必要があります。間違ったパスワードの再試行回数と繰り返し制限を設定する必要があります。

グループを使用してサブユーザーに権限を割り当てる

グループを作成することで、複数のサブユーザーを統合し、グループ全体に特定の権限を付与することができます。これにより、サブユーザーの権限とアクセスの管理と制御がより簡単かつ効率的になると同時に、個々のグループのアクセスを柔軟に管理できるようになります。

たとえば、管理者はさまざまなグループを作成し、さまざまなグループに異なる権限範囲を割り当てることができます。各サブユーザーに個別に権限を割り当てる必要はなく、適切なグループに割り当てるだけで済みます。これにより、管理者の時間と労力を大幅に節約できると同時に、アカウントのセキュリティを最大限に高めることができます。

さらに、グループは他のグループから権限を継承できるため、他のグループ内にサブグループを埋め込むことで権限を割り当てることができます。このアプローチにより、アカウント権限の管理と制御が容易になり、権限が合理的かつ細かく割り当てられるようになります。

コンソールユーザーとAPIユーザーを分離する

コンソール ユーザーは、クラウド サービスにログインするために使用されるアカウントであり、コンソールを管理する権限を持ちます。 API ユーザーは、クラウド サービスにアクセスするために使用されるアプリケーションであり、クラウド リソースにアクセスして管理する権限を持ちます。

コンソール ユーザーと API ユーザーを分離する理由は、2 種類のユーザーのアクセス権が異なり、分類して管理する必要があるためです。コンソール ユーザーは、クラウド リソースへのアクセス、作成、変更、削除など、さまざまな管理操作を実行できます。 API ユーザーは、ユーザーが指定した特定のリソースにアクセスして管理するだけでよいため、アクセス範囲は狭くなります。

2 種類のユーザーを分離することで、特定のユーザーの権限の漏洩によって生じるセキュリティ リスクを軽減できます。同時に、ユーザー権限の洗練された管理と制御もより適切に実現できます。たとえば、コンソール ユーザーがミスをしたり権限を乱用したりすることを心配することなく、必要に応じて API ユーザーに対して特定のリソース アクセス権限を承認または取り消すことができます。

ユーザーが不要になった権限をタイムリーに取り消す

ユーザーが特定の権限を必要としなくなった場合は、アカウントから削除するか、権限をダウングレードすることができます。これにより、アカウントがハッキングされたり漏洩したりするリスクが軽減され、セキュリティ管理者がアカウント権限をより適切に管理できるようになります。

権限を取り消す際には、権限の削除と更新が安全かつスムーズに実行されるように、詳細な一連のプロセスと仕様を開発できます。たとえば、プロセス中に、複数の権限の取り消しに対して異なる有効期間を設定できます。さまざまな権限の取り消しのための試用期間を設定する。新しい管理者がアカウント権限を常に把握できるように、詳細な管理および引き継ぎプロセスを開発します。

マスターアカウントのパスワードの共有を禁止する

複数のユーザーが同じアカウントとパスワードを共有すると、アカウントのセキュリティが脅かされ、ハッカーの攻撃や漏洩に対して脆弱になり、重要なユーザーデータや情報が失われる可能性があります。

さらに、複数の人が同じアカウントのパスワードを共有すると、他の問題が発生します。たとえば、ユーザーごとに異なるアクセス権を持つ必要があり、共有アカウントでは個別の権限設定を行うことはできません。同時に、共有アカウントではユーザーの行動を追跡・管理することが難しくなり、ユーザーの操作やトラフィックの使用状況を正確に監視することが不可能になります。

したがって、マスター アカウント パスワードの共有を禁止すると、ユーザー アカウントのセキュリティが保護されるだけでなく、ユーザー エクスペリエンスとシステム セキュリティ管理の向上にも役立ちます。複数の人が同じプラットフォームまたはサービスにアクセスする必要がある場合は、複数のサブアカウントを使用して、異なる権限とアクセス スコープを割り当て、アカウントのセキュリティと管理を確保できます。

マスターアカウントのアクセスキーを作成しないでください

アクセス キーは、実際には、プライマリ アカウントとパスワードを使用せずにクラウド サービスを認証および承認するために使用される一時的な資格情報のセットです。プライマリ アカウントとパスワードとは異なり、アクセス キーはいつでも作成および取り消すことができるため、アカウントのセキュリティが強化されます。ただし、マスター アカウントの権限が高すぎるため、アクセス キーが適切に管理されておらず、誤って漏洩した場合、ハッカーはこれらの資格情報を使用してユーザーのアカウントにアクセスし、機密情報を盗むことができ、サブ アカウントのアクセス キーの漏洩よりもはるかに有害です。

4.3.3 権限割り当てプロセス

1. ユーザーIDの認証

ユーザーを承認する前に、まずユーザーの身元を確認し、ユーザーの本名、役職、部署などの情報を確認して、正しい人物が承認されていることを確認する必要があります。

2. 認可戦略を策定する

企業は、さまざまな役割に対して、対応する認可戦略を策定し、実際のニーズに応じてユーザーに適切な権限を割り当て、「最小権限の原則」と「ニーズに基づく認可」の原則に従って厳密に実装する必要があります。

3. 承認リクエストを承認する

ユーザーが権限を申請する場合、上司の承認が必要です。承認者は、ユーザーの身元と適用された権限の合理性を確認し、実際の状況に基づいて申請を承認する必要があります。

4. 権限を割り当てる

承認後、ユーザーには承認ポリシーに基づいて対応する権限が割り当てられ、ユーザーに必要な最小限の権限のみが付与され、過剰な承認によって生じるリスクや脆弱性が防止されます。

5. 権限の定期的な見直し

各ロールの権限テンプレートを定期的に確認し、必要な権限が含まれていて、不要な権限が含まれていないことを確認します。各ユーザー/ロールの権限を確認し、権限が最新かつ適切であることを確認します。セキュリティ イベント ログを監査して、不正な権限要求や使用がないか確認します。

6. ユーザー権限の取り消し

ユーザーが権限を必要としなくなったら、直ちに権限を取り消します。退職または異動したユーザーの権限は直ちに取り消す必要があります。

4.4 セキュリティ管理

4.4.1 ネットワークセキュリティ

4.4.1.1 外部ネットワークへのオープンアクセス

サーバーが外部ネットワークにアクセスしたり、外部サービスを提供したりする必要がある場合、セキュリティ上のリスクが生じるため、EIP を ECS に直接バインドすることはできません。代わりに、ユーザーはセキュリティと信頼性を確保するために特定の仕様に従って構成する必要があります。

最初のステップはEIPとNATリソースを申請することです

EIP (Elastic IP Address) は、動的に割り当ておよび解放できるパブリック IP アドレスです。クラウド プラットフォームでは、ユーザーはこれを申請してクラウド サーバー インスタンスにバインドし、インスタンスへのパブリック ネットワーク アクセスを有効にできます。ただし、セキュリティを確保するため、ユーザーは EIP をクラウド サーバーに直接バインドすることはできません。ユーザーは NAT ゲートウェイを申請し、SNAT を使用して ECS プライベート IP アドレスをパブリック EIP アドレスに変換し、外部通信を可能にする必要があります。

ステップ2: SNATとDNATの設定、クラウドファイアウォールの設定を申請する

SNAT (Source Network Address Translation) は、イントラネット IP アドレスをエクストラネット IP アドレスに変換して、イントラネットとエクストラネット間の通信を可能にするソース アドレス変換テクノロジです。クラウド プラットフォームでは、ユーザーは SNAT エントリを構成することでこの機能を実装できます。

DNAT (宛先ネットワーク アドレス変換) は、外部 IP アドレスを内部 IP アドレスに変換し、パブリック ネットワークから内部ネットワーク リソースにアクセスできるようにする宛先アドレス変換テクノロジです。クラウド プラットフォームでは、ユーザーは DNAT エントリを構成することでこの機能を実装できます。

さらに、ユーザーはネットワーク セキュリティを確保するために、クラウド サーバーのクラウド ファイアウォール ルールを構成する必要もあります。ファイアウォール ルールを追加することで、ユーザーは受信トラフィックと送信トラフィックを制限し、悪意のある攻撃やデータ漏洩を回避できます。

つまり、サービスをパブリック インターネットに公開する必要があるかどうかに関係なく、EIP をクラウド サーバーに直接バインドしないでください。代わりに、仕様に従って関連するネットワーク構成を実行してください。これにより、ネットワークのセキュリティと信頼性が効果的に向上します。

4.4.1.2 ファイアウォールの設定

クラウド資産のセキュリティを保護するには、クラウドでファイアウォールを構成する必要があり、ファイアウォールの管理はセキュリティ部門によって均一に実行されます。外部ネットワークリソースの取得を例にとると、最初にユーザーは内部で需要を確認し、次にリーダーとのコミュニケーションと確認後にセキュリティ部門に作業注文を送信する必要があります。作業指示は、各マシンがアクセスする必要があるリソース名、タイプ、およびマシン名を詳細に説明する必要があります。これにより、セキュリティ部門はこの情報に基づいてファイアウォールルールを迅速かつ正確に設定できます。これにより、システムのセキュリティと安定性が確保され、悪意のある攻撃とデータの漏れを防ぎ、企業の通常の運用とビジネス開発を確保できます。

4.4.1.3ネットワーク部門

クラウド環境では、仮想プライベートネットワーク（VPC）テクノロジーを使用して、異なる部門間のネットワーク分離とセキュリティを実現できます。複数の部門が実際のニーズに応じて同じVPCを共有する必要がある場合、VPC内のネットワークをセグメント化する必要があり、各部門に対応するスイッチを作成する必要があります。このようにして、異なる部門間のネットワークは、互いに干渉することなく互いに通信できます。

VPCでは、唯一の制限はセキュリティグループを通じて制御されます。セキュリティグループは、VPCの内外を制御するために使用できるネットワークセキュリティサービスです。セキュリティグループルールを設定することにより、VPC内の異なる部門間のトラフィックを制限し、必要なトラフィックのみを通過させることができます。このようにして、VPC内の各部門のネットワークセキュリティを保証でき、ネットワーク攻撃やデータリークなどのリスクを防ぐことができます。

VPCとセキュリティグループを使用すると、ネットワークセキュリティのリスクを完全に排除することはできず、クラウドリソースを保護するために他の測定値がまだ必要であることに注意してください。包括的なセキュリティ戦略を通じてのみ、クラウドリソースのセキュリティと信頼性を保証できます。

4.4.2操作およびメンテナンスセキュリティ補強

セキュリティミドルウェアコンポーネントを使用して、以下を含むシステムとアプリケーションのセキュリティ強化をインストールおよび実行します。

最小特権の原則に従ってください。

未使用のアカウントを無効または削除します。

個別のユーザー管理、許可管理、リソース管理。

ルート許可を無効にします。

マスターアカウントのアクセスキーを作成しないでください。

APIユーザーからユーザーを分離します。

SSHのデフォルトポート番号とアプリケーションを変更します。

未使用のサービスとポートを無効にします。

・外部IPログインを制限します。

ユーザーログイン警告情報を追加します。

・リモートサーバーログインのSMSと電子メールアラートを設定します。

・ログイン時間制限を設定し、必要に応じて定期的にパスワードを変更します。

・セキュリティグループポリシーを整理し、ビジネスアクセスに関する洗練されたアクセス制御を実行します。

・RDS、Redisなどのホワイトリストをセットアップします。

4.4.3クラウドサーバーセキュリティグループアクセスポリシー

クラウドサーバーのセキュリティグループは、ネットワークセキュリティの分離の重要な手段であるファイアウォール機能を提供します。セキュリティグループ間でセキュリティルールを設定することにより、アクセスセキュリティを実現するためにマルチレイヤーアクセス制御システムを確立できます。

アプリケーションサーバー、データベース、データサーバーへの接続へのアクセスを制御するために、アプリケーション、データ、および管理のセキュリティグループを確立します。以下のセキュリティグループアクセス制御ルールは簡単な例であり、実際の特定のセキュリティ要件に従って調整されます。

1）Webサーバーグループルールの例

2）データベースサーバーグループルールの例

4.4.4運用監査

クラウドプラットフォームはすべて、クラウドプラットフォームアカウントの下ですべての操作ログを記録できる操作監査機能を提供します。 Alibaba Cloudには操作監査機能があり、Tencent Cloudにはクラウド監査機能があります。この機能を通じて、ユーザーはアカウントの下でのすべての操作のステータスを明確に理解することができます。これには、どの担当者が実行されたとき、操作が実行されたときなどを実行しました。これは、Alibabaクラウドリソースを管理し、アカウントセキュリティを確保するために非常に重要です。

Alibaba Cloudの操作監査機能を有効にするには、ユーザーは最初にAlibaba Cloud Consoleで監査ログサービス（SLS）プロジェクトを作成し、プロジェクトに監査する必要があるクラウドアカウントを追加する必要があります。次に、コンソールに監査ポリシーを設定して、どの操作を記録する必要があるかを定義します。

Tencent Cloudアカウントを作成すると、クラウド監査が有効になり、さまざまなクラウド製品に自動的に接続されます。 Tencent Cloudアカウントでアクティビティが発生すると、アクティビティはクラウド監査イベントに記録されます。ユーザーは、イベント履歴にアクセスすることで、クラウド監査コンソールのイベントを簡単に表示できます。

操作監査/クラウド監査機能が有効になると、ユーザーはコンソールの監査ログを照会して、アカウントのすべての操作の詳細を理解できます。さらに、クラウドプラットフォームはリアルタイムの監視とアラーム機能も提供しているため、ユーザーはタイムリーに異常な操作のアラートを受け取り、タイムリーな手段を講じることができます。

要するに、クラウドプラットフォームの操作監査機能は、クラウドプラットフォームリソースの管理とアカウントセキュリティの確保に非常に役立ちます。ユーザーはこの機能を合理的に使用することをお勧めします。