起業初期では、企業はクラウドリソースに対するセキュリティ要件が低いため、すべてのリソースに対する操作を一つのアクセスキーで行えるかもしれませんが、 企業が成長するにつれて、大量のカスタマーをクラウドへ移行し、組織の構成がますます複雑化していきます。 クラウドリソースに対するセキュリティ管理の要件も高くなる一方です。

本ドキュメントでは、事業主の視点から、企業は業務をクラウドへ移行後のリソースアクセス管理(RAM)に対する ニーズを分析し、 RAMを利用して安心安全なリソース管理システムを構築する方法を、わかりやすい事例から段階的に説明していきたいと思います。

事例研究

たとえば、X社の事業主であるとします。X社のためにクラウドアカウント (company-x@aliyun.com)を新規登録し、ECS、RDS及びOOSの基本インフラストラクチャーサービスを 購入しました。 会社のサービスをクラウドに移行して以来、ビジネスは発展を遂げ、チームは拡大し、クラウドリソースも増加しつつある。 リソースに対するすべての操作及び管理は一つの共有アカウントを使用しているため、システムの安全性やセキュリティの重要性が問題になっている。

X社の組織構成は下図の通りとします。 人事(HR)、研究開発(R&D)、オペレーション&メンテナンス(O&M)の合計3つの部門があります。 人事部は人事管理のみを担当、研究開発部はリソースの使用を担当、O&M部はリソースの管理(バーチャルマシンの実行や停止など)権限を付与されています。

図 1. X社の組織構成

実装手順

RAMを通じてリソースアクセスのセキュリティ管理を実現する方法を説明します。

ステップ1:プライマリアカウントの多段階認証(MFA)を有効にします

プライマリアカウントを他人に共有していることから考えて、パスワードが漏洩している可能性が非常に高いです。 プライマリアカウントのMFA(多段階認証認証)を有効にすることを 強くお勧めします。

AlibabaクラウドアカウントにはスタンダードバーチャルMFAに対応しています。 それはモバイルデバイス(スマホやスマートウォッチなど)にインストールできる、便利なアプリケーションです。 アカウントセンターでバーチャルMFAを有効にすると、 Alibabaクラウドプラットフォームへのログインは、ユーザー名とパスワード(第1段階認証)だけではなく、バーチャルMFAアプリにより生成された動的セキュリティコード(第2段階認証)の 入力も要求されます。 この2つの認証の組み合わせで、アカウントのセキュリティを強化します。

ステップ2:ユーザーアカウントを作成しグループに加わる

上記の組織図に基づいて、社員A、B、C、D、Eにそれぞれアカウントを作成し、アプリケーション「APP」にユーザーアカウントを作成します。 そして人事部、研究開発部、O&M部門のそれぞれに対応した3つの ユーザーグループを作成し、ユーザーを適切なグループに追加します。(ユーザーDは研究開発部とO&M部門の両方に属します)。

次に、RAM ユーザーの作成を参照してユーザーログインパスワードやアクセスキーを設定しなければなりません。

  • アプリケーション「APP」は、OpenAPIを使用しないとクラウドリソースへアクセスできないので、アクセスキーのみ作成してあげればいいです。
  • 社員は、コンソールでクラウドリソースを操作する必要がある場合、その社員にログインパスワードを設定してあげればいいです。

さらに、O&M操作は通常機密性が高いから、 メンテナンス担当者のアカウント情報が漏洩するような重大なリスクが懸念されることがあります。 この問題に対処するには、アカウントログイン時の強制MFA認証を設定することができます。さらにアカウントパスワードとMFAデバイスの管理をそれぞれ2人の担当者に割り当てます。 そうすることで、特定の操作は2人が同時にいる限り行うことができます。

ステップ3:それぞれのユーザーグループに必要最小限の権限を付与

RAMは、複数のシステム権限付与ポリシーテンプレートを提供しています。 たとえば、O&MグループにECS、RDSの完全権限、研究開発グループにECS、RDSの読み取り専用権限及びOSSの完全権限、 人事グループにRAMユーザー管理権限を付与することができます。

RAMのシステム権限付与ポリシーテンプレートの精度が不十分だと感じる場合は、 RAMで権限付与ポリシーテンプレートをカスタマイズすることができます カスタマイズ権限付与ポリシーは、APIの操作名や、リソースインスタンス名など、 きめ細かいアクセス管理に対応しています。 さらに、オペレータのソースIPを制限するなど、リソースの操作方法を柔軟に管理できる 多重条件式に対応しています。 カスタマイズ権限付与ポリシーは、ユーザーからの必要最小限な権限付与というニーズに応えるため、リソース管理に対する多様かつ厳格な要件を満たすことができます。 これで必要最小限の権限のみ付与できます。

条件付き権限付与の例を挙げますと、 研究開発担当者のアクセスキーの漏洩により会社のOSSデータに影響を及ぶことが懸念される場合、OSSのデータアクセスに制限をかけることができます。 たとえば、勤務時間中 (acs:CurrentTime条件式を使用)、企業サイトacs:SourceIP条件式を使用)でのみOSS操作を実行できるなどの制限を、 研究開発グループにかけることができます。

ステップ4:社員の転勤、入社及び退職

社員は転勤する場合、その社員のアカウントを転勤先のグループに移動することができます。 新入社員の場合は、新規アカウントを作成し、ログインパスワードやアクセスキーを設定して、適切なユーザーグループに追加します。 RAM ユーザーへの権限付与. . 社員は退職する場合、RAMコンソールで ユーザーアカウントを削除できます、同時にこのユーザーアカウントのすべてのアクセス権限をRAM により自動的に削除されます。

ステップ5:STSを通じて一時的なユーザーに権限を付与

場合によって、クラウドリソースへのアドホックアクセスを必要とするユーザー(ユーザーやアプリ)もいたりします。 そのようなユーザーを「一時的なユーザー」と呼ぶことにします。 本シナリオでは、RAMの拡張権限付与サービスであるセキュリティトークンサービス(STS)を 通じて、それらのユーザーにアクセストークンを発行できます。 トークンの権限と自動有効期限は、トークンを発行する段階で必要に応じて調整できます。

一時的ユーザーの権限付与にSTSアクセストークンを使用するメリットは、ユーザー権限付与をよりよく管理できることです。 一時的ユーザーのためにRAMユーザーアカウントの作成や パスワードの設定を行う必要がありません。 それは、RAMユーザーのパスワードは常に有効にする必要がありますが、一時的ユーザーは長時間にリソースにアクセスする必要がないからである。

また、STSを通じてRAMユーザーにアクセストークンを発行する権限を付与することができます。

ステップ6:プライマリアカウントを[寝かせます]

社員とアプリケーションシステムはRAMユーザーアカウントを使用し始めると、 日常業務にプライマリアカウントを使用する必要がなくなります。 漏洩防止のため、プライマリアカウントにアクセスキーを作成しないようお勧めします。

また、プライマリアカウントのパスワードとMFAデバイスを会社の安全な場所に保管して、「寝かせる」ことをお勧めします。