OpsCLI ® Advanced Compute Operation

OpsCLI: AWSアカウント作成ガイド

作成者:

OpsCLI

公開日:

2023-05-22

AWSアカウント作成ガイドの目的

本ガイドは、このガイドを閲覧している皆様が、セキュリティリスクやサービス環境への副作用を最小限に抑えながらOpsCLIのハンズオンを行うために必要な、AWSアカウントの作り方・取扱い上の考え方をご理解いただくために公開しています。

ハンズオンにおけるAWSアカウントの利用

ハンズオンにおけるトラブル

数多くのハンズオンに参加したり、運営の立場から参加していると、以下のようなトラブルを見聞きすることが珍しくありません。

1. 本番環境や重要な検証環境を破壊してしまった。

本番アカウントや重要な検証用アカウントでハンズオンを実施してしまったため、ハンズオンの手順(特に、更新手順やクリーンアップ手順など)により、重要なリソースを変更・削除してしまった、というケースは決して珍しくありません。

ハンズオンは、このような本番アカウントや重要な検証環境で行ってはいけません。

2. 失敗を前提としていない環境で失敗してしまった。

本番環境や、重要な検証用環境を一時的にハンズオンに転用し、変更に失敗した、元に戻せなくなった、というケースもあります。 例えば、ハンズオン前の情報を残しておかなかったことにより、戻すことができなくなるケースなどがこれに該当します。

ハンズオンは、失敗しても元に戻せる環境、最悪の状況になったら全部消してやりなおすことが許される環境で行うべきです。

3. ハンズオンのコストが気付かないまま継続的に課金されてしまった。

ハンズオン以外の用途で利用しているAWSアカウントでハンズオンを実施してしまうと、ハンズオン時に消し忘れなどで残ってしまったリソースのコストが、他の用途によるAWSコストに埋没してしまい、気付かずに大きな金額になってしまった、というケースも良く起こります。

ハンズオン用のコストは、他の用途とは独立して算出・検出できるようにしておきましょう。

ハンズオン環境の要件

以上のトラブルを避けるために、以下の要件を満たす「ハンズオン用のAWSアカウント」をご用意・ご利用いただくことをお奨めいたします。

  • 本番とは分離された環境

  • 失敗を前提とした環境

  • コストが独立した環境

../_images/env-requirement.png

ただ、利用者にとっては「ハンズオン用途」のアカウントであっても、その権限の奪取を狙っている攻撃者から見れば、本番環境同様に「一つのAWSアカウント」です。 セキュリティ保護の観点からは、本番環境と同様・同等の対策が必要となる点については、ご留意ください。

ハンズオン用AWSアカウントの大原則

ハンズオン環境の要件を満たすためには、以下の3つの大原則に従って、AWSアカウントをご用意いただく必要があります。

  1. ハンズオン専用のAWSアカウントを用意する。

  2. 個人別にAWSアカウントを用意する。

  3. AWSアカウントの証跡は取得する。

../_images/env-principle.png

AWSアカウントの作成には、1アカウントにつき1つのメールアドレスが必要となります。

その管理工数やライフサイクルを考えた場合、ハンズオン用のAWSアカウントとして、サンドボックスサービス等の利用をご検討した方が良い場合もあります。

AWSアカウントの利用形態

ハンズオン用のAWSアカウントを、自社で調達・管理する場合、以下の2つの形態があります。

AWSアカウント (単独)

旧来のAWSアカウント利用の形態で、操作、操作対象、証跡、支払いの全てが1つのAWSアカウントに存在しています。

../_images/account-standalone.png

この形態では、

  • 一つひとつのAWSアカウントに証跡の設定が必要。(rootアカウントが証跡の改竄や消去をできてしまう。)

  • 利用リージョンを一括して制限することができない。(個別に制限を付与することは可能だが、設定漏れがあると想定外の利用ができてしまう可能性がある。)

というデメリットがあります。

Organizations組織

現在、主流となっているAWSアカウント利用の形態で、支払いとサービスへのガードレールを親アカウントで行い、証跡を証跡アカウントで管理し、操作と操作対象が子アカウントに存在する形になります。

../_images/account-organizations.png

この形態では、

  • 子アカウントのアクセス制御に対するガードレールを一元的に設定できる。(子アカウントのrootアカウントも制限できる。)

  • 証跡を集約して管理するため、アクセスできる人を絞りやすい、監査がしやすい。

  • 子アカウントは、AWSサービスの利用に集中できる。(設定漏れリスクが相対的に低い)

というメリットがあります。

ただし、親アカウント自身にガードレールの設定をすることはできないため、支払いとアクセス制限以外を親アカウントにはさせないことがベストプラクティスになります。

AWSアカウントの作成

AWSアカウントの作成

AWSアカウントの作成については、公式サイトの「AWSアカウント作成の流れ」( https://aws.amazon.com/jp/register-flow/ )をご参照ください。

AWSアカウント作成後のセキュリティ対策については、AWS Hands-on for Beginners 「アカウント作成後すぐやるセキュリティ対策」( https://pages.awscloud.com/JAPAN-event-OE-Hands-on-for-Beginners-Security-1-2022-reg-event.html )をご参照ください。

Organizations組織の構築

Organizations( https://aws.amazon.com/jp/organizations/ )組織を構築し、AWSサービスの実運用は子アカウントで行い、親アカウントは支払いと、子アカウントのアクセス制御のみを行うことをご検討ください。

また、"AWS Control Tower"( https://aws.amazon.com/jp/controltower/ )を活用することも有用です。