Amazon Web Services ブログ

Category: Identity

AWS Systems Manager Automation を使用して複数のアカウントとリージョンにある AWS リソースを管理する

AWS Systems Manager Automation で AWS リソースの一般的な管理およびメンテナンスタスクが容易になります。Systems Manager Automation を使用すると、ご自分で記述したりコミュニティで公開されたドキュメントを使用したりできる AWS Systems Manager ドキュメント(SSM ドキュメント)の形式で前もって定義済みのタスクやワークフローを実行できます。SSM ドキュメントは、Systems Manager が AWS リソースに対して実行するアクションを定義しますこれらのドキュメントは Systems Manager メンテナンスウィンドウを使ってスケジューリングが可能です。さらに、Amazon CloudWatch Events を使用して、AWS リソースへの変更に基づいてドキュメントをトリガーしたり、AWS マネジメントコンソール、AWS CLI、または AWS SDK を通して直接実行したりできます。ドキュメントの各ステップでの実行を追跡したり、ステップの承認を要求したりできます。また、変更を段階的にロールアウトして、エラーが発生した際に自動停止することもできます。 AWS のお客様の多くは複数の AWS アカウントを使用しています。たいていは、AWS Organizations を使用してアカウントを階層に配置し、それらを組織単位(OU)にグループ化しています。OU は、一括請求 (コンソリデーティッドビリング)、ワークロードの分離、管理の分離など、さまざまな目的に使用できます。お客様は、アプリケーションごとに開発、テスト、ステージング、および本番用に個別のアカウントを組織内で作成することがよくあります。 すべてのアカウントに共通する反復的なタスクがあっても、前述のマルチアカウント構造ではそれらを個別に管理することは困難な場合があります。お客様から、次のような一般的なタスクを 1 つの中央/管理アカウントから実行したいとの要望がありました。 パッチ管理 ゴールデン Amazon マシンイメージ (AMI) の作成 SSM エージェントを使用したソフトウェアエージェントの更新 Amazon EC2 インスタンスの開始/停止/再起動 Amazon […]

Read More

re:Invent 2019 の AWS アイデンティティセッション、ワークショップ、チョークトークのご案内

AWS re:Invent 2019 が間近にせまってきました! 参加するセッションの優先順位をつけないといけませんね。そこで AWS re:Invent 2019 での AWS Identity セッション、ワークショップ、チョークトークのリストをご用意しました。re:Invent にまだ登録していない場合は、社内承認のためのテンプレートがありますのでこちらもご利用ください。 AWS アイデンティ リーダシップ キーノート SEC207-L — Leadership session: AWS identity (Breakout session) リーダーシップセッション: AWS アイデンティティ (ブレイクアウトセッション) デジタルアイデンティティは、クラウドで最も急速に成長し、最も急速に変化している領域の1つです。ゼロトラストネットワーク、GDPRの懸念、および新しい IoT の機会がニュースでよく報道されています。このセッションではこの重要な業界の変化について触れ、お客様とその顧客の両方のアイデンティティにアプローチする AWS の方法について学びます。 新機能の発表や、オープンスタンダードと業界グループへの取り組みについて議論し、アイデンティティ、アクセス制御、リソース管理をより簡単にする方法を説明します。 自社環境向けの AWS アイデンティティ マネジメント FSI310 — The journey to least privilege: IAM for Financial Services (Chalk talk) 最小権限への旅:金融サービスのための IAM (チョークトーク) AWS […]

Read More

プログラムからのアクセス利用時に AWS アカウントを保護するためのガイドライン

AWS を利用する際に最も重要なこととして、AWS リソースのセキュリティの確保があります。誰にリソースにアクセスさせるのか、注意深くコントロールする必要があります。これは、AWS ユーザーがプログラムを使ったアクセスをしている場合にも同様です。プログラムからのアクセスは、自社で作成したアプリケーションもしくはサードパーティーのツールから AWS リソースにアクションすることを実現します。AWS サービス側でアクセスリクエストを認可させるためにアクセスキー ID とシークレットアクセスキーを使ってリクエストに署名することが可能です。このようにプログラムによるアクセスは非常にパワフルなため、アクセスキー ID とシークレットアクセスキーを保護するためにベスト・プラクティスを活用することが重要です。これは不意のアクセスあるいは悪意のあるアクテビティビティからアカウントを保護するために重要です。この投稿では、いくつかの基本的なガイドラインを提示し、アカウントを保護する方法を示します。また、プログラムからの AWS リソースへのアクセスを行う際に利用出来るいくつかの方法を提示します。 ルートアカウントを保護する AWS のルートアカウント –  AWS にサインナップするときに最初に作られるアカウント – は全ての AWS のリソースに無制限でアクセス出来ます。ルートアカウントには権限による制御が効きません。したがって、AWS はルートアカウントに対してアクセスキーを作成しないように常におすすめしています。アクセスキーを与えると利用者がアカウント全体を廃止するような強力な権限を得てしまいます。ルートアカウントにアクセスキーを作成するかわりに、利用者は個別の AWS Identity and Access Management(IAM)ユーザーを作成して利用することができます。さらに、最小権限の考え方に従い、それぞれの IAM ユーザーに対してタスクを実行するのに必要な権限のみを許可します。複数の IAM ユーザーの権限を簡単に管理するために、同じ権限を持つユーザーを IAM グループにまとめる方法も使えます。 ルートアカウントは常に多要素認証(MFA)で保護するべきです。このセキュリティに関する追加の保護は許可されていないログインからアカウントを保護することに役立ちます。多要素認証とは、認証に複数の要素を使うことで、パスワードのような知識認証要素と、MFA デバイスのような所有物認証要素を同時に使うことです。 AWS はバーチャルとハードウェアの 両方のMFA 用のデバイス、さらに U2F セキュリティキーを多要素認証用としてサポートしています。 AWS アカウントに対するアクセスを許可するときの考え方 ユーザーに AWS マネジメントコンソールやコマンドラインインターフェース(CLI)にアクセスを許可するには2つの選択肢があります。1つ目は、IAM サービスによって管理されるユーザー名とパスワードでログインする ID を作ることです。もう1つは、IDフェデレーションを利用して、既に企業の中に存在する認証情報を使って AWS コンソールや CLI にログインさせることです。それぞれのアプローチには異なるユースケースがあります。フェデレーションは、既に集中管理されたディレクトリがあるか、現在の制約である5000人以上の IAM […]

Read More