翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# セキュリティと権限
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
各ユーザーには、アカウントの AWS リソースにアクセスするための適切な AWS 認証情報が必要です。ユーザーに認証情報を提供する推奨方法は、 [AWS Identity and Access Management](https://docs.aws.amazon.com/iam/) (IAM) を使用することです。 OpsWorks スタックは IAM と統合され、以下を制御できます。
+ 個々のユーザーが OpsWorks スタックとやり取りする方法。
たとえば、あるユーザーに対してはスタックへのアプリケーションのデプロイはできるが、スタック自体の変更はできないようにし、他のユーザーに対しては特定のスタックに限定してフルアクセスができるようにします。
+ スタックがユーザーに代わって Amazon EC2 OpsWorks インスタンスや Amazon S3 バケットなどのスタックリソースにアクセスする方法。 Amazon EC2
OpsWorks スタックは、これらのタスクのアクセス許可を付与するサービスロールを提供します。
+ スタックによって制御される Amazon EC2 OpsWorks インスタンスで実行されるアプリケーションが、Amazon S3 バケットに保存されているデータなど、他の AWS リソースにアクセスする方法。
インスタンスプロファイルを Layer のインスタンスに割り当てることで、それらのインスタンスで実行されているアプリケーションが他の AWS リソースにアクセスするためのアクセス許可を付与できます。
+ ユーザーベースの SSH キーを管理し、SSH または RDP によりインスタンスに接続する方法
スタックごとに、管理ユーザーは、各 ユーザーに個人 SSH キーを割り当てたり、ユーザーに自身のキーの指定を許可したりできます。また、各ユーザーのスタックのインスタンスに対する SSH または RDP アクセスと、sudo または管理者特権を許可できます。
セキュリティのその他の側面には、次のようなものがあります。
+ 最新のセキュリティパッチによるインスタンスのオペレーティングシステムの更新を管理する方法。
詳細については、「[セキュリティ更新の管理](workingsecurity-updates.md)」を参照してください。
+ インスタンスとの間で送受信されるネットワークトラフィックを [Amazon EC2 security groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) (Amazon EC2 セキュリティグループ) で制御するように設定する方法。
OpsWorks スタックのデフォルトのセキュリティグループの代わりにカスタムセキュリティグループを指定する方法。詳細については、「[セキュリティグループの使用](workingsecurity-groups.md)」を参照してください。
**Topics**
+ [OpsWorks スタックのユーザーアクセス許可の管理](opsworks-security-users.md)
+ [OpsWorks スタックがユーザーに代わって動作することを許可する](opsworks-security-servicerole.md)
+ [OpsWorks スタックでのサービス間の混乱した代理の防止](cross-service-confused-deputy-prevention-stacks.md)
+ [EC2 インスタンスで実行するアプリケーションに対するアクセス許可の指定](opsworks-security-appsrole.md)
+ [SSH アクセスの管理](security-ssh-access.md)
+ [Linux セキュリティ更新の管理](workingsecurity-updates.md)
+ [セキュリティグループの使用](workingsecurity-groups.md)
# OpsWorks スタックのユーザーアクセス許可の管理
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
ベストプラクティスとして、 OpsWorks スタックユーザーを指定された一連のアクションまたは一連のスタックリソースに制限します。 OpsWorks スタックユーザーアクセス許可は、 スタックアクセス**許可**ページを使用する方法と、適切な IAM ポリシーを適用する方法の 2 OpsWorks つの方法で制御できます。
OpsWorks**[Permissions]** (許可) ページまたは同等の CLI または API アクションにより、各ユーザーに複数の *[permission levels]* (パーミッションレベル) の 1 つを割り当てることで、マルチユーザー環境のユーザー許可をスタックごとに制御できます。それぞれのレベルで付与される権限は、特定のスタックリソースに対する標準的なアクション一式に対応します。[**Permissions**] ページを使用して制御できる権限は次のとおりです。
+ 各スタックにアクセスできるユーザー。
+ 個々のユーザーが各スタックに対して実行できるアクション。
たとえば、一部のユーザーにはスタックの閲覧のみを許可する一方で、他のユーザーにはアプリケーションのデプロイ、インスタンスの追加などを許可することができます。
+ 各スタックを管理できるユーザー。
指定したユーザー (複数可) に各スタックの管理を委任できます。
+ 各スタックの Amazon EC2 インスタンスにおけるユーザーレベルの SSH アクセスと sudo 特権 (Linux) または RDP アクセスと管理者特権 (Windows) を持つ人。
個々のユーザーについて、これらの権限をいつでも許可したり取り消したりすることができます。
**重要**
SSH/RDP アクセスを拒否しても、必ずしもユーザーがインスタンスにログインできなくなるわけではありません。インスタンスに Amazon EC2 キーペアを指定した場合、対応するプライベートキーを持つユーザーは誰でもログインするかキーを使用して Windows 管理者パスワードを取得できます。詳細については、「[SSH アクセスの管理](security-ssh-access.md)」を参照してください。
[IAM コンソール](https://console.aws.amazon.com/iam)、 CLI または API から、 OpsWorks スタックの各種リソースやアクションに対するアクセス許可を明示的に付与するポリシーをユーザーに追加することもできます。
+ 権限は、IAM ポリシーを使用した方が、権限レベルで行うよりも柔軟に指定できます。
+ [IAM ID (ユーザー、ユーザーグループ、ロール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) を設定して、ユーザーやユーザーグループなどの IAM ID にアクセス権限を付与したり、フェデレーションユーザーに関連付けられる[ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)を定義したりできます。
+ IAM ポリシーは、特定のキー OpsWorks スタックアクションのアクセス許可を付与する唯一の方法です。
例えば、`opsworks:CreateStack` と `opsworks:CloneStack` (それぞれスタックの作成とクローン化に使用) へのアクセス権限を付与するには、IAM を使用する必要があります。
コンソールでフェデレーティッドユーザーをインポートすることは明示的には不可能ですが、フェデレーティッドユーザーは、 OpsWorks スタックコンソールの右上にある**「マイ設定**」を選択し、右上にある**「ユーザー**」を選択することで、暗黙的にユーザープロファイルを作成できます。**ユーザー** ページで、API または CLI を使用して作成された、またはコンソールを通じて暗黙的に作成されたアカウントのフェデレーティッドユーザーは、非フェデレーティッド IAM ユーザーと同じ様にアカウントを管理できます。
この 2 つのアプローチは相互排他的なものではなく、両者を組み合わせることで利便性が高まることもあります。両者を組み合わせて使用した場合、両方の権限の集合が OpsWorks スタックによって評価されます。たとえば、インスタンスの追加と削除は許可するが、レイヤーの追加と削除をユーザーに許可するのは望ましくないとします。 OpsWorks スタックのアクセス許可レベルはいずれも、その特定のアクセス許可セットを付与しません。ただし、**許可** ページを使用して、**管理** 権限レベルをユーザーに付与し、ほとんどのスタック操作を許可したうえで、レイヤーの追加と削除の権限を拒否する IAM ポリシーを適用することは可能です。詳細については、[[のポリシーを使用して AWS リソースへのアクセスを制御する]](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)を参照してください。
ユーザーの権限を管理するための標準的なモデルを以下に示します。いずれのケースも、ここではお客様が管理ユーザーであるという前提で記述しています。
1. 一人または複数の管理ユーザーには、[IAM コンソール](https://console.aws.amazon.com/iam)を使用して AWSOpsWorks\$1FullAccess ポリシーを適用します。
1. 非管理ユーザーそれぞれに、 OpsWorks スタックの権限が付与されていないポリシーで ユーザーを作成します。
ユーザーが OpsWorks スタックにのみアクセスする必要がある場合は、ポリシーをまったく適用する必要はありません。代わりに、 OpsWorks スタックのアクセス許可ページでアクセス**許可**を管理できます。
1. OpsWorks スタック**ユーザー**ページを使用して、管理者以外のユーザーを OpsWorks スタックにインポートします。
1. スタックごとにその [**Permissions**] ページを使用し、それぞれのユーザーに権限レベルを割り当てます。
1. 必要に応じて、適切に構成した IAM ポリシーを適用し、ユーザーの権限レベルをカスタマイズします。
ユーザー管理に関する推奨事項については、「[ベストプラクティス: アクセス権限の管理](best-practices-permissions.md)」を参照してください。
IAM でのベストプラクティスの詳細については、IAM ユーザーガイドの「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
**Topics**
+ [OpsWorks スタックユーザーの管理](opsworks-security-users-manage.md)
+ [OpsWorks スタックごとのアクセス許可をスタックユーザーに付与する](opsworks-security-users-console.md)
+ [IAM ポリシーをアタッチして OpsWorks スタックのアクセス許可を管理する](opsworks-security-users-policy.md)
+ [ポリシーの例](opsworks-security-users-examples.md)
+ [OpsWorks スタックのアクセス許可レベル](opsworks-security-users-standard.md)
# OpsWorks スタックユーザーの管理
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
ユーザーを OpsWorks スタックにインポートしてアクセス許可を付与する前に、まず個人ごとにユーザーを作成しておく必要があります。IAM ユーザーを作成するには、まず IAMFullAccess ポリシーで定義された権限が付与されている IAM ユーザーとして AWS にサインインします。次に、IAM コンソールを使用して、 OpsWorks スタックにアクセスする必要があるすべてのユーザーの [IAM ユーザーを作成します](opsworks-security-users-create-user.md)。その後、これらのユーザーを OpsWorks スタックにインポートし、次のようにユーザーアクセス許可を付与できます。
**通常の OpsWorks スタックユーザー**
標準ユーザーには、アタッチされたポリシーは不要です。スタックがある場合は、通常 OpsWorks 、スタックのアクセス許可は含まれません。代わりに、 OpsWorks スタックの**アクセス許可** ページを使用して、スタックstack-by-stack通常のユーザーに次のいずれかのアクセス許可レベルを割り当てます。
+ **Show** 権限: ユーザーは、スタックを表示することはできますが、その他のオペレーションは一切実行できません。
+ **Deploy** 権限: **Show** 権限に加えて、アプリケーションのデプロイと更新が許可されます。
+ **Manage** 権限: **Deploy** 権限に加え、スタック管理操作を実行できます。たとえば、レイヤーやインスタンスを追加したり、[**Permissions**] ページを使ってユーザーの権限を設定したり、自分の SSH/RDP と sudo/admin 特権を有効にしたりすることができます。
+ **Deny** 権限: スタックへのアクセスは拒否されます。
これらのパーミッションレベルが特定のユーザーにとって必要なものでない場合、IAMポリシーを適用することでユーザーのパーミッションをカスタマイズすることができます。たとえば、 OpsWorks スタックの**アクセス許可** ページを使用して、アクセス許可**の管理**レベルをユーザーに割り当てます。これにより、すべてのスタック管理オペレーションを実行するアクセス許可がユーザーに付与されますが、スタックを作成またはクローンすることはできません。そこで、レイヤーの追加や削除を許可しないことでそれらの権限を制限したり、スタックの作成やクローンを許可することでそれらの権限を増強するポリシーを適用することができます。詳細については、「[IAM ポリシーをアタッチして OpsWorks スタックのアクセス許可を管理するIAM ポリシーをアタッチする](opsworks-security-users-policy.md)」を参照してください。
**OpsWorks スタック管理ユーザー**
管理ユーザーは、アカウント所有者または [[AWSOpsWorks\$1FullAccess ポリシー]](opsworks-security-users-examples.md#opsworks-security-users-examples-admin) で定義された権限を持つ IAM ユーザーです。このポリシーには、**Manage** ユーザーに付与される権限に加え、[**Permissions**] ページでは付与することのできない以下のようなアクションの権限が含まれます。
+ OpsWorks スタックへのユーザーのインポート
+ スタックの作成とクローン化
ポリシー全体については、「[ポリシーの例](opsworks-security-users-examples.md)」を参照してください。IAMポリシーを適用することによってのみユーザーに付与できる権限の詳細なリストについては、「[OpsWorks スタックのアクセス許可レベル権限レベル](opsworks-security-users-standard.md)」を参照してください。
**Topics**
+ [ユーザーとリージョン](#UsersandRegions)
+ [OpsWorks スタック管理ユーザーの作成](opsworks-security-users-manage-admin.md)
+ [OpsWorks スタックの IAM ユーザーの作成](opsworks-security-users-create-user.md)
+ [OpsWorks スタックへのユーザーのインポート](opsworks-security-users-manage-import.md)
+ [OpsWorks スタックのユーザー設定の編集](opsworks-security-users-manage-edit.md)
## ユーザーとリージョン
OpsWorks スタックユーザーは、作成されたリージョンエンドポイント内で使用できます。以下のどのリージョンにもユーザーを作成できます。
+ 米国東部 (オハイオ) リージョン
+ 米国東部(バージニア州北部) リージョン
+ 米国西部 (オレゴン) リージョン
+ 米国西部 (北カリフォルニア) リージョン
+ カナダ (中部) リージョン (API のみ。 では使用できません AWS マネジメントコンソール
+ アジアパシフィック (ムンバイ) リージョン
+ アジアパシフィック (シンガポール) リージョン
+ アジアパシフィック (シドニー) リージョン
+ アジアパシフィック (東京) リージョン
+ Asia Pacific (Seoul) Region
+ 欧州 (フランクフルト) リージョン
+ 欧州 (アイルランド) リージョン
+ 欧州 (ロンドン) リージョン
+ 欧州 (パリ) リージョン
+ 南米 (サンパウロ) リージョン
OpsWorks スタックにユーザーをインポートするときは、リージョンエンドポイントの 1 つにインポートします。複数のリージョンでユーザーを使用できるようにするには、そのリージョンにユーザーをインポートする必要があります。 OpsWorks スタックユーザーをあるリージョンから別のリージョンにインポートすることもできます。同じ名前のユーザーが既に存在するリージョンにユーザーをインポートすると、インポートされたユーザーは既存のユーザーを置き換えます。ユーザーのインポートの詳細については、[ユーザーのインポート](opsworks-security-users-manage-import.md)を参照してください。
# OpsWorks スタック管理ユーザーの作成
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
OpsWorks スタック管理ユーザーを作成するには、`AWSOpsWorks_FullAccess`ポリシーをユーザーに追加して、そのユーザーに OpsWorks スタックフルアクセス許可を付与します。管理ユーザーの作成について詳しくは、「[管理ユーザーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-set-up.html#create-an-admin)」を参照してください。
**注記**
AWSOpsWorks\$1FullAccess ポリシーが適用されたユーザーは、 OpsWorks スタックのスタックを作成したり管理したりすることができますが、ユーザーはスタックの IAM サービスロールを作成することができません。既存のロールを使用する必要があります。スタックを最初に作成するユーザーには別途、「[管理権限](opsworks-security-users-examples.md#opsworks-security-users-examples-admin)」で説明されている IAM 権限が必要です。このユーザーが最初のスタックを作成すると、 OpsWorks スタックは必要なアクセス許可を持つ IAM サービスロールを作成します。以後、`opsworks:CreateStack` 権限を持つユーザーは、そのロール使って別のスタックを作成することができます。詳細については、「[OpsWorks スタックがユーザーに代わって動作することを許可する](opsworks-security-servicerole.md)」を参照してください。
ユーザーを作成すると、必要に応じてカスタマー管理ポリシーを追加してユーザーの権限を微調整できます。たとえば、スタックの作成と削除を管理ユーザーに許可する一方で、新しいユーザーのインポートは禁止することができます。詳細については、「[IAM ポリシーをアタッチして OpsWorks スタックのアクセス許可を管理するIAM ポリシーをアタッチする](opsworks-security-users-policy.md)」を参照してください。
複数の管理ユーザーが存在する場合は、各ユーザーに個別にアクセス許可を設定するのではなく、AWSOpsWorks\$1FullAccess ポリシーを IAM グループ にアタッチし、そのグループにユーザーを追加するようにします。
グループの作成の詳細については、[「IAM ユーザー」を参照してください](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_create.html)。グループを作成したら、**AWSOPSWorks\$1FullAccess** ポリシーを追加します。また、**AWSOpsWorks\$1FullAccess** パーミッションを含む**AdministratorAccess**ポリシーを追加することもできます。
既存のグループにアクセス権限を追加する方法については、「[IAM ユーザーグループへのポリシーのアタッチ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_attach-policy.html)」を参照してください。
# OpsWorks スタックの IAM ユーザーの作成
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
IAM ユーザーを OpsWorks スタックにインポートする前に、それらを作成する必要があります。これは、[IAM console](https://console.aws.amazon.com/iam/) (IAM コンソール)、コマンドライン、または API のいずれかを使用して実行できます。詳細な手順については、[AWS 「アカウントでの IAM ユーザーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html)」を参照してください。
[管理ユーザー](opsworks-security-users-manage-admin.md)とは異なり、権限を定義するためにポリシーをアタッチする必要はありません。権限は、[ユーザーを OpsWorks スタックにインポート](opsworks-security-users-manage-import.md)した後で設定できます (「[ユーザー許可の管理](opsworks-security-users.md)」を参照)。
IAMユーザーとグループの作成の詳細については、[「IAM の使用開始」](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html) を参照してください。
# OpsWorks スタックへのユーザーのインポート
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
管理ユーザーは、ユーザーを OpsWorks スタックにインポートできます。また、あるリージョンのエンドポイントから別のリージョン OpsWorks のエンドポイントに スタックユーザーをインポートすることもできます。ユーザーを OpsWorks スタックにインポートするときは、いずれかの OpsWorks スタックリージョンエンドポイントにインポートします。ユーザーを複数のリージョンで使用できるようにするには、該当するリージョンにユーザーをインポートする必要があります。
コンソールでフェデレーティッドユーザーをインポートすることは明示的には不可能ですが、フェデレーティッドユーザーは、 OpsWorks スタックコンソールの右上にある**マイ設定**を選択し、右上にある**ユーザー**を選択することで、暗黙的にユーザープロファイルを作成できます。**ユーザー** ページで、API または CLI を使用して作成された、またはコンソールを通じて暗黙的に作成されたアカウントのフェデレーティッドユーザーは、非フェデレーティッド IAM ユーザーと同じ様にアカウントを管理できます。
**ユーザーを OpsWorks スタックにインポートするには**
1. 管理ユーザーまたはアカウント所有者として OpsWorks スタックにサインインします。
1. 右上の [**Users**] を選択して [**Users**] ページを開きます。
![\[us-east-1 users を表示する [Users] ページ\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/permissions_users_page.png)
1. [**Import IAM Users to <*リージョン名*>**] を選択し、使用可能なユーザーアカウントのうちまだインポートされていないものを表示します。
![\[[Users] ページへのコマンドのインポート\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/permissions_import.png)
1. [**Select all**] チェックボックスをオンにするか、個別のユーザーを 1 つ以上選択します。完了後、[**Import to OpsWorks**] を選択します。
**注記**
ユーザーを OpsWorks スタックにインポートした後、IAM コンソールまたは API を使用してアカウントからユーザーを削除しても、ユーザーは OpsWorks スタックを通じて付与した SSH アクセスを自動的に失うことはありません。また、ユーザーページを開き、**ユーザーの****アクション**列で**削除**を選択して、 OpsWorks スタックからユーザーを削除する必要があります。
**OpsWorks スタックユーザーをあるリージョンから別のリージョンにインポートするには**
OpsWorks スタックユーザーは、作成されたリージョンエンドポイント内で使用できます。[ユーザーとリージョン](opsworks-security-users-manage.md#UsersandRegions) に表示されているリージョンでユーザーを作成できます。
OpsWorks スタックユーザーを 1 つのリージョンから**、ユーザー**リストが現在フィルタリングされているリージョンにインポートできます。インポート先のリージョンにすでに同じ名前のユーザーが設定されている場合、既存のユーザーはインポートされたユーザーに置き換わります。
1. 管理ユーザーまたはアカウント所有者として OpsWorks スタックにサインインします。
1. 右上の [**Users**] を選択して [**Users**] ページを開きます。複数のリージョンに OpsWorks スタックユーザーがいる場合は、**フィルター**コントロールを使用して、ユーザーをインポートするリージョンをフィルタリングします。
![\[us-east-1 users を表示する [Users] ページ\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/permissions_users_page.png)
1. **別のリージョンから <*current region*> OpsWorks へのスタックユーザーのインポート**を選択します。
![\[us-west-2 users を表示する [Users] ページ\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/permissions_import_otherregion.png)
1. OpsWorks スタックユーザーをインポートするリージョンを選択します。
1. インポートするユーザーを選択するか (複数可)、すべてのユーザーを選択して、[**Import to this region**] を選択します。 OpsWorks スタックがインポートされたユーザーを**ユーザー**リストに表示するまで待ちます。
## スタックの外部で作成された Unix IDs OpsWorks とユーザー
OpsWorks は OpsWorks 、スタックインスタンスの Unix ID (UID) 値を 2000 から 4000 の間で割り当てます。は 2000-4000 の範囲の UIDs OpsWorks を予約するため、 の外部で作成したユーザー OpsWorks (クックブックレシピを使用するか、IAM OpsWorks から にユーザーをインポートするなど) は、別のユーザーの スタックによって OpsWorks 上書きされる UIDs を持つことができます。これにより、 OpsWorks スタックの外部で作成したユーザーがデータバッグの検索結果に表示されなかったり、 OpsWorks スタックの組み込み`sync_remote_users`オペレーションから除外されたりする可能性があります。
外部プロセスでは、スタックが上書きできる UIDs OpsWorks を持つユーザーを作成することもできます。たとえば一部のオペレーティングシステムパッケージはインストール後のプロセスの一環としてユーザーを作成することができます。ユーザーまたはソフトウェアプロセスが、デフォルトである UID を明示的に指定せずに Linux ベースのオペレーティングシステムにユーザーを作成する場合、スタックによって割り当てられた UID は *<既存の OpsWorks UID> の最大値* \$1 OpsWorks 1 です。
ベストプラクティスとして、 OpsWorks スタックユーザーを作成し、 OpsWorks スタックコンソールで AWS CLI、または AWS SDK を使用してアクセスを管理します。の外部にある OpsWorks スタックインスタンスでユーザーを作成する場合は OpsWorks、4000 を超える *UnixID* 値を使用します。
# OpsWorks スタックのユーザー設定の編集
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
ユーザーをインポートした後、次の手順に従って、それらのユーザーの設定を編集することができます。
**ユーザーの設定を編集するには**
1. **ユーザー**ページのユーザーの**アクション**列で **編集** を選択します。
1. 次の設定を指定できます。
**Self Management**
ユーザーが [MySettings] ページを使用して個人 SSH キーを指定できるように許可するには、[**Yes**] を選択します。
また、[[DescribeMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeMyUserProfile.html)] アクションと [[UpdateMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateMyUserProfile.html)] アクションの権限を付与する IAM ポリシーをユーザーにアタッチすることで、自己管理を可能にすることができます。
**Public SSH key**
(オプション) ユーザーのパブリック SSH キーを入力します。このキーは、ユーザーの [**My Settings**] ページに表示されます。自己管理が有効にされている場合、ユーザーは [**My Settings**] を編集し、独自のキーを指定できます。詳細については、「[ユーザーのパブリック SSH キーの登録](security-settingsshkey.md)」を参照してください。
OpsWorks スタックはすべての Linux インスタンスにこのキーをインストールします。ユーザーは関連するプライベートキーを使用してログインできます。詳細については、「[SSH でのログイン](workinginstances-ssh.md)」を参照してください。Windows のスタックでこのキーを使用することはできません。
**アクセス許可**
(オプション) 各スタックに対してユーザーが持つ権限レベルを、各スタックの [**Permissions**] ページで個別に設定するのではなく、一箇所で設定します。権限レベルの詳細については、「[スタックごとの権限の付与](opsworks-security-users-console.md)」を参照してください。
![\[User details page showing name, ARN, SSH settings, and permission levels for various stacks.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/permissions_edit_user.png)
# OpsWorks スタックごとのアクセス許可をスタックユーザーに付与する
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
OpsWorks スタックのユーザーアクセス許可を管理する最も簡単な方法は、スタックのアクセス**許可**ページを使用することです。各スタックには、その権限を付与するページがそれぞれに存在します。
何らかの権限設定に変更を加える場合は、管理ユーザーまたは **Manage** ユーザーとしてサインインする必要があります。リストには、 OpsWorks スタックにインポートされたユーザーのみが表示されます。ユーザーの作成とインポートの方法については、「[ユーザーの管理](opsworks-security-users-manage.md)」を参照してください。
デフォルトの権限レベルはIAMポリシーのみで、IAMポリシーにある権限のみがユーザーに付与されます。
+ IAM または別のリージョンからユーザーをインポートする際、ユーザーは既存のすべてのスタックのリストに **IAM Policies Only** (IAMポリシーのみ) 権限レベルで追加されます。
+ デフォルトでは、別のリージョンからインポートされたユーザーは、インポート先のリージョンのスタックにアクセスできません。別のリージョンからインポートしたユーザーがインポート先のリージョンを管理できるようにするには、インポートしたユーザーにこれらのスタックへのアクセス権限を割り当てる必要があります。
+ 新しいスタックを作成すると、現在の全ユーザーが、**IAM Policies Only** の権限レベルでリストに追加されます。
**Topics**
+ [ユーザーの権限の設定](#opsworks-security-users-console-set)
+ [権限の表示](#opsworks-security-users-console-viewing)
+ [IAM 条件キーを使用した一時認証情報の確認](#w2ab1c14c67c15c37c21)
## ユーザーの権限の設定
**ユーザーの権限を設定するには**
1. ナビゲーションペインの [**アクセス権限**] を選択します。
1. [**Permissions**] ページの [**Edit**] を選択します。
1. [**Permission level**] と [**Instance access**] の設定を変更します。
+ [**Permissions level**] の設定を使用して、いずれかの標準権限レベルをユーザーごとに割り当てます。そのスタックにユーザーがアクセスできるかどうかや、どのようなアクションを実行できるかが、この設定によって決まります。ユーザーに IAM ポリシーがある場合、 OpsWorks Stacks は両方のアクセス許可セットを評価します。例については、「[ポリシーの例](opsworks-security-users-examples.md)」を参照してください。
+ [**Instance access** **SSH/RDP**] 設定は、ユーザーがスタックのインスタンスに SSH (Linux) または RDP (Windows) アクセスできるかどうかを指定します。
**SSH/RDP** アクセスを許可した場合、オプションで **sudo/admin** を選択できます。これにより、ユーザーにスタックのインスタンスでの sudo (Linux) または管理者 (Windows) 特権が付与されます。
![\[[Permissions] ページでの IAM ユーザーの管理。\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/permissions-edit.png)
ユーザーにはそれぞれ、次のいずれかの権限レベルを割り当てることができます。各レベルによって許可される一連のアクションについては、「[OpsWorks スタックのアクセス許可レベル権限レベル](opsworks-security-users-standard.md)」を参照してください。
**拒否**
スタック OpsWorks にフルアクセス許可を付与する IAM ポリシーがあっても、ユーザーは OpsWorks スタックに対してスタックアクションを実行できません。未リリース製品のスタックに対する一部のユーザーのアクセスを拒否する場合などに使用します。
**IAM Policies Only**
新しくインポートされたすべてのユーザー、および新しく作成されたスタックのすべてのユーザーに割り当てられるデフォルトのレベルです。アタッチされている IAM ポリシーによって、ユーザーの権限が決まります。ユーザーに IAM ポリシーがない場合、またはポリシーに明示的な OpsWorks スタックアクセス許可がない場合、ユーザーはスタックにアクセスできません。管理ユーザーは、IAMポリシーによってすでにフルアクセス権限が付与されているため、通常このレベルが割り当てられます。
**[表示]**
ユーザーはスタックを表示できますが、一切オペレーションは実行できません。たとえば、マネージャは通常、アカウントのスタックを必要に応じて監視しますが、アプリケーションをデプロイしたりスタックに変更を加えたりする必要はありません。
**デプロイ**
**Show** 権限に加えて、アプリケーションをデプロイすることがユーザーに許可されます。たとえば、アプリケーション開発者は、必要に応じてスタックのインスタンスに対する更新をデプロイしますが、スタックにレイヤーやインスタンスを追加する必要はありません。
**管理**
**Deploy** 権限に加え、さまざまなスタック管理オペレーションがユーザーに許可されます。その例を次に示します。
+ レイヤーやインスタンスを追加または削除する。
+ スタックの [**Permissions**] ページを使用して権限レベルをユーザーに割り当てる。
+ リソースを登録または登録を解除する。
たとえば、スタック内のインスタンスの数とタイプを適切に保ち、パッケージやオペレーティングシステムの更新処理を担うマネージャをスタックごとに指定できます。
Manage レベルのユーザーがスタックを作成したり、スタックをクローン化したりすることはできません。これらの権限は、IAMポリシーによって付与されなけれる必要があります。例については、[アクセス許可の管理](opsworks-security-users-examples.md#opsworks-security-users-examples-manage)を参照してください。
ユーザーにも IAM ポリシーがある場合、 OpsWorks Stacks は両方のアクセス許可セットを評価します。これにより、ユーザーに権限レベルを割り当て、ポリシーを適用して、そのレベルで許可されるアクションを制限または強化することができます。たとえば、スタックの作成とクローン化を許可したり、リソースの登録と登録解除を拒否したりするポリシーを **管理** ユーザーにアタッチすることができます。そうしたポリシーの例については、「[ポリシーの例](opsworks-security-users-examples.md)」を参照してください。
**注記**
ユーザーのポリシーによって追加のアクションが許可された場合、[**Permissions**] ページの設定が見かけ上オーバーライドされます。たとえば、ユーザーが[レイヤーの作成](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html) アクションを許可するポリシーを持っていても、**許可** ページを使用して **デプロイ** 許可を指定した場合でも、ユーザーは依然としてレイヤーを作成することができます。このルールでは **[Deny]** (拒否) オプションは例外です。AWSOpsWorks\$1FullAccess ポリシーがアタッチされていても、ユーザーのスタックアクセスが拒否されます。詳細については、「 [ポリシーを使用した AWS リソースへのアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)」を参照してください。
## 権限の表示
[自己管理](opsworks-security-users-manage-edit.md)が有効になっている場合、ユーザーは、右上の [**My Settings**] を選択することで、すべてのスタックに関して自分に割り当てられている権限レベルの概要を表示できます。ユーザーは、アタッチされたポリシーで [DescribeMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeMyUserProfile.html) アクションと [UpdateMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateMyUserProfile.html) アクションの権限が付与されていれば、**自分の設定** にもアクセスできます。
## IAM 条件キーを使用した一時認証情報の確認
OpsWorks には、追加の認可ケース (個々のユーザーに対するスタックへの読み取り専用または読み取り/書き込みのアクセスの簡易化された管理など) をサポートする組み込みの認可レイヤーがあります。この認可レイヤーは、一時認証情報の使用に依存しています。このため、IAM ドキュメントの[「条件キーの有無をチェックする条件演算子」](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_Null)で説明されているように、ユーザーが長期的な認証情報を使用していることを確認したり、一時認証情報を使用しているユーザーのアクションをブロックしたりするために、`aws:TokenIssueTime` 条件を使用することはできません。
# IAM ポリシーをアタッチして OpsWorks スタックのアクセス許可を管理する
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
IAM ポリシーをアタッチすることで、ユーザーの OpsWorks スタックアクセス許可を指定できます。次に示す一部の権限については、ポリシーのアタッチが必須となります。
+ 管理ユーザー権限 (ユーザーのインポートなど)。
+ 特定のアクションの権限 (スタックの作成、スタックのクローン化など)。
アタッチされたポリシーが必要となる全アクションの一覧については、「[OpsWorks スタックのアクセス許可レベル権限レベル](opsworks-security-users-standard.md)」を参照してください。
ポリシーを使用することによって、**許可** ページで付与された権限レベルをカスタマイズすることもできます。このセクションでは、IAM ポリシーをユーザーに適用して OpsWorks スタックのアクセス許可を指定する方法の概要を示します。詳細については、「 [AWS リソースのアクセス管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)」を参照してください。
IAM ポリシーは、1 つ以上の *statements* (ステートメント) を含んだ JSON オブジェクトです。各ステートメント要素には、一連の権限が記述され、それぞれ 3 つの基本要素が存在します。
**アクション**
権限の対象となるアクション。 OpsWorks スタックアクションを として指定します`opsworks:action`。`Action` には、特定のアクションを指定できます。例えば、`opsworks:CreateStack` は、[https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateStack.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateStack.html) の呼び出しをユーザーに許可するかどうかを指定します。また、ワイルドカードを使用して複数のアクションをまとめて指定することもできます。例えば、すべての作成アクションを指定するには、`opsworks:Create*` とします。スタックアクションの完全なリストについては、 OpsWorks [OpsWorks 「 スタック API リファレンス](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html)」を参照してください。
**[Effect]** (効果)
指定したアクションを許可するか拒否するかを示します。
**[リソース]**
アクセス許可が影響する AWS リソース。 OpsWorks スタックには、スタックという 1 つのリソースタイプがあります。特定のスタックリソースの権限を指定するには、`Resource` 形式で、スタックの ARN を `arn:aws:opsworks:region:account_id:stack/stack_id/` に指定します。
また、ワイルドカードを使用することもできます。例えば、`Resource` を `*` に設定すると、すべてのリソースに対する権限が付与されます。
たとえば、次のポリシーでは、ID が `2860-2f18b4cb-4de5-4429-a149-ff7da9f0d8ee` であるスタックのインスタンスをユーザーが停止できないようにしています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "opsworks:StopInstance",
"Effect": "Deny",
"Resource": "arn:aws:opsworks:*:*:stack/2f18b4cb-4de5-4429-a149-ff7da9f0d8ee/"
}
]
}
```
------
IAM ユーザーに権限を付与する方法の詳細については、「[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。
IAM ポリシーの作成や変更を行う方法の詳細については、[許可とポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。 OpsWorks スタックポリシーの例については、「」を参照してください[ポリシーの例](opsworks-security-users-examples.md)。
# ポリシーの例
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
このセクションでは、 スタックユーザーに適用できる IAM OpsWorks ポリシーの例について説明します。
+ [管理権限](#opsworks-security-users-examples-admin) では、管理ユーザーに権限を付与するために使用されるポリシーを説明します。
+ [アクセス許可の管理](#opsworks-security-users-examples-manage) と [Deploy 権限](#opsworks-security-users-examples-deploy) では、管理とデプロイの権限レベルを補足したり制限したりする目的でユーザーに適用できるポリシーの例を紹介します。
OpsWorks スタックは、IAM ポリシーによって付与されたアクセス許可と、 アクセス許可ページによって付与されたアクセス許可を評価することで、ユーザーの**アクセス許可**を決定します。詳細については、「 [ポリシーを使用した AWS リソースへのアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)」を参照してください。[**Permissions**] ページの権限の詳細については、「[OpsWorks スタックのアクセス許可レベル権限レベル](opsworks-security-users-standard.md)」を参照してください。
## 管理権限
IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を使用して AWSOpsWorks\$1FullAccess ポリシーにアクセスします。このポリシーをユーザーにアタッチして、すべての OpsWorks スタックアクションを実行するアクセス許可を付与します。ユーザーのインポートを管理ユーザーに許可するなど、特定の操作については、IAM の権限が必須となります。
スタックがユーザーに代わって Amazon EC2 インスタンスなどの他の AWS リソースにアクセスできるようにする [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)を作成する必要があります。 OpsWorks 通常、このタスクを処理するには、管理者ユーザーに最初のスタックを作成し、 OpsWorks スタックにロールを作成します。以後そのロールは、後続のすべてのスタックで使用することができます。詳細については、「[OpsWorks スタックがユーザーに代わって動作することを許可する](opsworks-security-servicerole.md)」を参照してください。
最初のスタックを作成する管理ユーザーは、AWSOpsWorks\$1FullAccess ポリシーに含まれていない特定の IAM アクションに対する権限を持っている必要があります。ポリシーの `Actions` セクションに、次のアクセス許可を追加します。適切な JSON 構文のために、アクション間にカンマを追加し、アクションのリストの末尾にあるコンマを削除してください。
```
"iam:PutRolePolicy",
"iam:AddRoleToInstanceProfile",
"iam:CreateInstanceProfile",
"iam:CreateRole"
```
## アクセス許可の管理
**Manage** 権限レベルのユーザーは、レイヤーの追加と削除を含め、さまざまなスタック管理アクションを実行できます。このトピックでは、**管理** ユーザーにアタッチすることで、標準の権限を制限したり補足したりできるいくつかのポリシーについて説明します。
**Manage** ユーザーによるレイヤーの追加と削除を拒否する
**管理** 権限レベルを制限し、レイヤーの追加と削除を除くすべての **管理** アクションの実行を許可するには、次の IAM ポリシーをアタッチします。*リージョン*、*account\$1id*、および *stack\$1id* を設定に適した値に置き換えます。
スタックの作成とクローン化を **Manage** ユーザーに許可する
**Manage** (管理) 権限レベルでは、スタックの作成もクローン化も許可されません。以下の IAM ポリシーをアタッチすることで、ユーザーがスタックの作成やクローン化を作成できるように **管理** を変更することができます。*リージョン* および *account\$1id* を設定に適した値に置き換えます。
Manage ユーザーによるリソースの登録と登録解除を拒否する
**管理** 権限レベルのユーザーは、[スタックへの Amazon EBS と Elastic IP アドレスリソースの登録および登録解除](resources-reg.md)を行うことができます。リソースの登録を除くすべての **管理** アクションを許可するように **管理** 権限を制限するには、次のポリシーを適用します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"opsworks:RegisterVolume",
"opsworks:RegisterElasticIp"
],
"Resource": "*"
}
]
}
```
ユーザーのインポートを **Manage** ユーザーに許可する
アクセス許可**の管理**レベルでは、ユーザーは OpsWorks スタックにユーザーをインポートできません。ユーザーをインポートしたり削除したりできるように **管理** 権限を補足するには、次の IAM ポリシーを適用します。*リージョン* および *account\$1id* を設定に適した値に置き換えます。
## Deploy 権限
**Deploy** 権限レベルのユーザーは、アプリケーションを作成することも削除することもできません。アプリケーションを作成したり削除したりできるように **デプロイ** 権限を補足するには、次の IAM ポリシーをアタッチします。*リージョン*、*account\$1id*、および *stack\$1id* を設定に適した値に置き換えます。
# OpsWorks スタックのアクセス許可レベル
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
このセクションでは、 OpsWorks スタックのアクセス許可ページのアクセス許可レベルの**表示**、**デプロイ**、**管理**で許可されるアクションを一覧表示**します**。また、ユーザーにIAMポリシーを適用することによってのみパーミッションを与えることができるアクションのリストも含まれています。
**表示**
**表示** レベルでは、`DescribeXYZ` コマンドが許可されます。ただし次のコマンドは例外です。
```
DescribePermissions
DescribeUserProfiles
DescribeMyUserProfile
DescribeStackProvisioningParameters
```
ユーザーの自己管理を管理ユーザーが有効にした場合、**表示** 権限レベルのユーザーは、`DescribeMyUserProfile` と `UpdateMyUserProfile` も使用できます。自己管理の詳細については、「[ユーザー設定の編集](opsworks-security-users-manage-edit.md)」を参照してください。
**デプロイ**
**デプロイ** レベルでは、**表示** レベルで許可されるアクションに加えて次のアクションが許可されます。
```
CreateDeployment
UpdateApp
```
**管理**
**管理** レベルでは、**デプロイ** レベルと **表示** レベルで許可されるアクションに加えて次のアクションが許可されます。
```
AssignInstance
AssignVolume
AssociateElasticIp
AttachElasticLoadBalancer
CreateApp
CreateInstance
CreateLayer
DeleteApp
DeleteInstance
DeleteLayer
DeleteStack
DeregisterElasticIp
DeregisterInstance
DeregisterRdsDbInstance
DeregisterVolume
DescribePermissions
DetachElasticLoadBalancer
DisassociateElasticIp
GrantAccess
GetHostnameSuggestion
RebootInstance
RegisterElasticIp
RegisterInstance
RegisterRdsDbInstance
RegisterVolume
SetLoadBasedAutoScaling
SetPermission
SetTimeBasedAutoScaling
StartInstance
StartStack
StopInstance
StopStack
UnassignVolume
UpdateElasticIp
UpdateInstance
UpdateLayer
UpdateRdsDbInstance
UpdateStack
UpdateVolume
```
**Permissions That Require an IAM Policy** (IAM ポリシーを必要とする権限)
適切な IAM ポリシーをユーザーに適用して、以下のアクションの権限を付与する必要があります。例については、「[ポリシーの例](opsworks-security-users-examples.md)」を参照してください。
```
CloneStack
CreateStack
CreateUserProfile
DeleteUserProfile
DescribeUserProfiles
UpdateUserProfile
```
# OpsWorks スタックがユーザーに代わって動作することを許可する
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
OpsWorks スタックは、ユーザーに代わってさまざまな AWS サービスとやり取りする必要があります。例えば、 OpsWorks Stacks は、Amazon EC2 とやり取りしてインスタンスを作成し、Amazon CloudWatch とやり取りしてモニタリング統計を取得します。スタックを作成するときは、通常はサービスロールと呼ばれる IAM OpsWorks ロールを指定します。これにより、スタックに適切なアクセス許可が付与されます。
![\[[Add Stack] (スタックの追加) ページの IAM ロールリスト。\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/add-stack-iamrole.png)
新しいスタックのサービスロールを指定するときは、次のいずれかの操作を実行します。
+ 以前に作成した標準サービスロールを指定します。
通常は、最初のスタックの作成時に標準サービスロールを作成し、そのロールを以降のすべてのスタックに使用できます。
+ IAM コンソールまたは API を使用して作成したカスタムサービスロールを指定します。
このアプローチは、標準サービスロールよりも制限されたアクセス許可を OpsWorks スタックに付与する場合に便利です。
**注記**
最初のスタックを作成するには、IAM [**AdministratorAccess**] ポリシーテンプレートでアクセス権限が定義されている必要があります。これらの権限により、 OpsWorks スタックは新しいIAMサービスロールを作成し、[前述のように](opsworks-security-users-manage-import.md)ユーザーをインポートすることができます。以降のすべてのスタックでは、ユーザーは最初のスタック用に作成されたサービスロールを選択できます。スタックを作成するための完全な管理権限は必要ではありません。
標準サービスロールにより、次のアクセス許可が付与されます。
+ すべての Amazon EC2 アクションを実行する (`ec2:*`)。
+ CloudWatch 統計を取得する (`cloudwatch:GetMetricStatistics`)。
+ Elastic Load Balancing を使用してサーバーにトラフィックを分散させる (`elasticloadbalancing:*`)。
+ Amazon RDS インスタンスをデータベースサーバーとして使用する (`rds:*`)。
+ IAM ロール (`iam:PassRole`) を使用して、 スタックと Amazon EC2 OpsWorks インスタンス間の安全な通信を提供します。
カスタムサービスロールを作成する場合は、スタックの管理に必要なすべてのアクセス許可が OpsWorks スタックに付与されていることを確認する必要があります。次の JSON 例は、標準サービスロールのポリシーステートメントです。カスタムサービスロールのポリシーステートメントには、少なくとも以下のアクセス権限が含まれていなければなりません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:*",
"iam:PassRole",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"ecs:*",
"elasticloadbalancing:*",
"rds:*"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
}
}
}
]
}
```
------
また、サービスロールには信頼関係があります。 OpsWorks スタックによって作成されたサービスロールには、次の信頼関係があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "StsAssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "opsworks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
OpsWorks スタックがユーザーに代わって動作するには、サービスロールにこの信頼関係が必要です。デフォルトのサービスロールを使用する場合は、信頼関係を変更しないでください。カスタムサービスロールを作成する場合は、以下のいずれかを実行することで信頼関係を指定します。
+ [[AM console]](https://console.aws.amazon.com/iam/home#roles) (IAMコンソール) で **[Create role]** (ロールの作成) ウィザードを使用している場合は、**[Choose a use case]** (ユースケースの選択) で **[Opsworks]** を選択します。このロールには適切な信頼関係がありますが、暗黙のうちにアタッチされているポリシーはありません。 OpsWorks スタックにユーザーに代わって行動する権限を付与するために、以下を含むカスタマー管理ポリシーを作成し、新しいロールにアタッチします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarms",
"cloudwatch:GetMetricStatistics",
"ec2:*",
"ecs:*",
"elasticloadbalancing:*",
"iam:GetRolePolicy",
"iam:ListInstanceProfiles",
"iam:ListRoles",
"iam:ListUsers",
"rds:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
}
}
}
]
}
```
------
+ CloudFormation テンプレートを使用している場合は、テンプレートの**リソース**セクションに次のようなものを追加できます。
```
"Resources": {
"OpsWorksServiceRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"AssumeRolePolicyDocument": {
"Statement": [ {
"Effect": "Allow",
"Principal": {
"Service": [ "opsworks.amazonaws.com" ]
},
"Action": [ "sts:AssumeRole" ]
} ]
},
"Path": "/",
"Policies": [ {
"PolicyName": "opsworks-service",
"PolicyDocument": {
...
} ]
}
},
}
}
```
# OpsWorks スタックでのサービス間の混乱した代理の防止
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
混乱した代理問題は、アクションを実行する許可を持たないエンティティが、より特権のあるエンティティにアクションを実行するように強制できるセキュリティの問題です。では AWS、サービス間のなりすましにより、混乱した代理問題が発生する可能性があります。サービス間でのなりすましは、1 つのサービス (*呼び出し元サービス*) が、別のサービス (*呼び出し対象サービス*) を呼び出すときに発生する可能性があります。呼び出し元サービスは、本来ならアクセスすることが許可されるべきではない方法でその許可を使用して、別のお客様のリソースに対する処理を実行するように操作される場合があります。これを防ぐため、 AWS では、アカウントのリソースへのアクセス権が付与されたサービスプリンシパルで、すべてのサービスのデータを保護するために役立つツールを提供しています。
スタックアクセスポリシーで [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)および [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) グローバル条件コンテキストキーを使用して、 AWS OpsWorks スタックが別のサービスに付与するアクセス許可をスタックに制限することをお勧めします。`aws:SourceArn` の値に Amazon S3 バケット ARN などのアカウント ID が含まれていない場合は、両方のグローバル条件コンテキストキーを使用して、アクセス許可を制限する必要があります。同じポリシーステートメントでこれらのグローバル条件コンテキストキーの両方を使用し、アカウント ID に`aws:SourceArn` の値が含まれていない場合、`aws:SourceAccount` 値と `aws:SourceArn` 値の中のアカウントには、同じアカウント ID を使用する必要があります。クロスサービスのアクセスにスタックを 1 つだけ関連付けたい場合は、`aws:SourceArn` を使用します。クロスサービスが使用できるように、アカウント内の任意のスタックを関連づけたい場合は、`aws:SourceAccount` を使用します。
の値は、 OpsWorks スタックの ARN `aws:SourceArn`である必要があります。
混乱した代理問題から保護するための最も効果的な方法は、 OpsWorks スタックの完全な ARN を指定しながら、 `aws:SourceArn`グローバル条件コンテキストキーを使用することです。完全な ARN が不明な場合や、複数のサーバー ARN 場合には、ARN の不明な部分にワイルドカード (`*`) を含む `aws:SourceArn` グローバルコンテキスト条件キーを使用します。例えば、`arn:aws:servicename:*:123456789012:*`。
次のセクションでは、 スタックで OpsWorks `aws:SourceArn`および `aws:SourceAccount` グローバル条件コンテキストキーを使用して、混乱した代理問題を防ぐ方法を示します。
## OpsWorks スタックで混乱した代理の悪用を防ぐ
このセクションでは、 スタックで OpsWorks 混乱した代理悪用を防ぐ方法と、 スタックへのアクセスに使用している IAM ロールにアタッチできるアクセス許可ポリシーの例について説明します OpsWorks 。セキュリティのベストプラクティスとして、`aws:SourceArn` と `aws:SourceAccount` の条件キーを IAM ロールとほかのサービスとの信頼関係に追加することをお勧めします。信頼関係により OpsWorks 、 スタックは、 OpsWorks スタックスタックを作成または管理するために必要な他の サービスでアクションを実行するロールを引き受けることができます。
**信頼関係を編集するために、`aws:SourceArn` と `aws:SourceAccount` 条件キーを追加するには**
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. **検索**ボックスで、 OpsWorks スタックへのアクセスに使用するロールを検索します。 AWS マネージドロールは です`aws-opsworks-service-role`。
1. そのロールの **概要** ページで、**信頼関係** タブを選択します。
1. **信頼関係** タブで、**信頼ポリシーの編集** を選択します。
1. **[信頼ポリシーの編集]** ページで、少なくとも `aws:SourceArn` や `aws:SourceAccount` 条件キーの一つをポリシーに追加します。`aws:SourceArn` を使用して、クロスサービス (Amazon EC2 など) と OpsWorks スタック間の信頼関係を、より制限の厳しい特定の OpsWorks スタックスタックに制限します。`aws:SourceAccount` を追加して、クロスサービスと OpsWorks スタック間の信頼関係を、制限の少ない特定のアカウントのスタックに制限します。以下に例を示します。両方の条件キーを使用する場合、アカウント ID は同じでなければならないことに注意してください。
1. 条件キーの追加が終了したら、 [**更新ポリシー**] を選択します。
`aws:SourceArn` と `aws:SourceAccount` を使用してスタックへのアクセスを制限するロールのその他の例を以下に示します。
**Topics**
+ [例: 特定のリージョンのスタックへのアクセス](#confused-deputy-opsworks-stacks-example1)
+ [例: `aws:SourceArn` に複数のスタック ARN の追加](#confused-deputy-opsworks-stacks-example2)
### 例: 特定のリージョンのスタックへのアクセス
次のロール信頼関係ステートメントは、米国東部 (オハイオ) リージョン () のすべての OpsWorks スタックスタックにアクセスします`us-east-2`。リージョンは `aws:SourceArn` の ARN 値で指定されていますが、スタック ID の値はワイルドカード (\$1) であることに注意してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "opsworks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:opsworks:us-east-2:123456789012:stack/*"
}
}
}
]
}
```
------
### 例: `aws:SourceArn` に複数のスタック ARN の追加
次の例では、アカウント ID 123456789012 の OpsWorks 2 つの スタックスタックの配列へのアクセスを制限します。
# EC2 インスタンスで実行するアプリケーションに対するアクセス許可の指定
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
スタックの Amazon EC2 インスタンスで実行するアプリケーションが、Amazon S3 バケットなどの他の AWS リソースにアクセスするには、適切なアクセス許可が必要です。アクセス許可を付与するには、インスタンスプロファイルを使用します。[OpsWorks スタックスタックを作成するときに、](workingstacks-creating.md)インスタンスごとにインスタンスプロファイルを指定できます。
![\[[Add Stack] ページの高度なオプション。\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/add-stack-instanceproflie.png)
[レイヤー設定を編集](workinglayers-basics-edit.md)して、レイヤーのインスタンスのプロファイルを指定することも可能です。
インスタンスプロファイルにより、IAM ロールが指定されます。インスタンスで実行するアプリケーションは、ロールのポリシーによって付与されたアクセス許可に応じて、AWS リソースにアクセスするためにそのロールを引き受けることができます。アプリケーションがロールを引き受ける方法の詳細については、「[API コールを使用してロールを引き受ける](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-assume-role.html)」を参照してください。
次のいずれかの方法でインスタンスプロファイルを作成することができます。
+ IAM コンソールまたは API を使用して、プロファイルを作成します。
詳細については、「[ロール (委任とフェデレーション)](https://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html)」を参照してください。
+ CloudFormation テンプレートを使用してプロファイルを作成します。
IAM リソースをテンプレートに含める方法のいくつかの例については、[「Identity and Access Management (IAM) Template Snippets」](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html)(Identity and Access Management (IAM) テンプレートスニペット) を参照してください。
インスタンスプロファイルには信頼関係と AWS のリソースへのアクセス許可を付与するアタッチされたポリシーがあります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
OpsWorks スタックがユーザーに代わって動作するには、インスタンスプロファイルにこの信頼関係が必要です。デフォルトのサービスロールを使用する場合は、信頼関係を変更しないでください。カスタムサービスロールを作成する場合は、次のように信頼関係を指定します。
+ [[IAM console]](https://console.aws.amazon.com/iam/home#roles) (IAMコンソール) の**「Create Role」**(ロールロールの作成) ウィザードを使用している場合、ウィザードの2ページ目の **[AWS Service Roles]** (AWS サービスロール)で **[Amazon EC2]** (Amazon EC2) のロールタイプを指定します。
+ CloudFormation テンプレートを使用している場合は、テンプレートの**リソース**セクションに次のような内容を追加できます。
```
"Resources": {
"OpsWorksEC2Role": {
"Type": "AWS::IAM::Role",
"Properties": {
"AssumeRolePolicyDocument": {
"Statement": [ {
"Effect": "Allow",
"Principal": {
"Service": [ "ec2.amazonaws.com" ]
},
"Action": [ "sts:AssumeRole" ]
} ]
},
"Path": "/"
}
},
"RootInstanceProfile": {
"Type": "AWS::IAM::InstanceProfile",
"Properties": {
"Path": "/",
"Roles": [ {
"Ref": "OpsWorksEC2Role"
}
]
}
}
}
```
インスタンスプロファイルを作成すると、その時点でプロファイルのロールに適切なポリシーをアタッチできます。スタックを作成した後、[IAM console](https://console.aws.amazon.com/iam/) (IAM コンソール) または API を使用して、適切なポリシーをプロファイルのロールにアタッチする必要があります。たとえば、次のポリシーでは、amzn-s3-demo-bucket という名前の Amazon S3 バケット内のすべてのオブジェクトへのフルアクセスを許可します。*region* と amzn-s3-demo-bucket を、設定に適した値に置き換えます。
インスタンスプロファイルの作成および使用方法の例については、「[Amazon S3 バケットの使用](https://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted.walkthrough.photoapp.html)」を参照してください。
アプリケーションがインスタンスプロファイルを使用して EC2 インスタンスから OpsWorks スタック API を呼び出す場合、ポリシーは スタックやその他の AWS サービスに適切な`iam:PassRole`アクションに加えて OpsWorks 、 アクションを許可する必要があります。`iam:PassRole` アクセス許可により、 OpsWorks スタックがユーザーに代わってサービスロールを引き受けることができるようになります。 OpsWorks スタック API の詳細については、[AWS OpsWorksリファレンス](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html)」を参照してください。
以下は、EC2 インスタンスからスタックアクションを呼び出すこと、および Amazon EC2 OpsWorks または Amazon S3 アクションを呼び出すことを許可する IAM ポリシーの例です。
**注記**
を許可しない場合`iam:PassRole`、 OpsWorks スタックアクションの呼び出しは失敗し、次のようなエラーが発生します。
```
User: arn:aws:sts::123456789012:federated-user/Bob is not authorized
to perform: iam:PassRole on resource:
arn:aws:sts::123456789012:role/OpsWorksStackIamRole
```
アクセス許可に EC2 インスタンスのロールを使用する詳細については、[https://docs.aws.amazon.com/IAM/latest/UserGuide/role-usecase-ec2app.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/role-usecase-ec2app.html)ユーザーガイド*のAWS Identity and Access Management Amazon EC2 インスタンスで実行されるアプリケーションに、AWS リソースへのアクセスを付与する*を参照してください。
# SSH アクセスの管理
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
OpsWorks スタックは、Linux スタックと Windows スタックの両方の SSH キーをサポートします。
+ Linux インスタンスでは、[エージェント CLI](agent.md) コマンドを実行するためなど、インスタンスにログインするときに SSH を使用できます。
詳細については、「[SSH でのログイン](workinginstances-ssh.md)」を参照してください。
+ Windows インスタンスの場合、SSH キーを使用してインスタンスの管理者パスワードを取得してから、そのパスワードを使用して RDP でログインできます。
詳細については、「[RDP でのログイン](workinginstances-rdp.md)」を参照してください。
認証は、パブリックキーとプライベートキーで構成される SSH キーペアに基づきます。
+ インスタンスにパブリックキーをインストールします。
場所は特定のオペレーティングシステムによって異なりますが、 OpsWorks スタックによって詳細が処理されます。
+ プライベートキーをローカルに保存し、SSH クライアント (`ssh.exe` など) で指定して、インスタンスにアクセスします。
SSH クライアントはプライベートキーを使用して、インスタンスに接続します。
スタックのユーザーに SSH アクセス権限を与えるには、SSH キーペアを作成し、パブリックキーをスタックのインスタンスにインストールして、プライベートキーを安全に管理する方法が必要です。
Amazon EC2は、インスタンスにパブリック SSH キーをインストールする簡単な方法を提供します。Amazon EC2 コンソールまたは API を使用して、使用する予定の AWS リージョンごとに 1 つまたは複数のキーペアを作成できます。Amazon EC2 は公開キーを AWS に保存し、ユーザーはプライベートキーをローカルに保存します。インスタンスの起動時に、リージョンのいずれかのキーペアを指定すると、そのペアは Amazon EC2 でインスタンスに自動的にインストールされます。次に、対応するプライベートキーを使用して、インスタンスにログインします。詳細については、[「Amazon EC2 のキーペア」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) を参照してください。
OpsWorks スタックでは、スタックの作成時にリージョンの Amazon EC2 キーペアのいずれかを指定し、オプションで各インスタンスの作成時に別のキーペアで上書きできます。 OpsWorks スタックが対応する Amazon EC2インスタンスを起動するときにキーペアが指定され、Amazon EC2 でインスタンスにパブリックキーがインストールされます。その後、標準の Amazon EC2 インスタンスと同様に、プライベートキーを使用してログインしたり、管理者パスワードを取得したりできます。詳細については、「[Amazon EC2 キーをインストールする](security-settingec2key.md)」を参照してください。
Amazon EC2 のキーペアの使用は便利ですが、2 つの重要な制限があります。
+ Amazon EC2 キーペアは、特定の AWS リージョンに関連付けられています。
複数のリージョンで作業する場合、複数のキーペアを管理しなければなりません。
+ 1 つのインスタンスにインストールできる Amazon EC2 キーペアは 1 つだけです。
複数のユーザーにログインを許可する場合、そのすべてがプライベートキーのコピーを所有する必要がありますが、セキュリティ上、これは推奨されません。
Linux スタックの場合、 OpsWorks スタックは SSH キーペアをよりシンプルで柔軟に管理する方法を提供します。
+ ユーザーは各自、個人キーペアを登録します。
で説明されているように、プライベートキーをローカルに保存し、パブリックキーを OpsWorks スタックに登録します[ユーザーのパブリック SSH キーの登録](security-settingsshkey.md)。
+ スタックのユーザーアクセス権限を設定した場合、どのユーザーにスタックのインスタンスに対する SSH アクセスを付与するかを指定します。
OpsWorks スタックは、承認された各ユーザーのスタックのインスタンスにシステムユーザーを自動的に作成し、パブリックキーをインストールします。これでユーザーは、「[SSH でのログイン](workinginstances-ssh.md)」で説明しているように、対応するプライベートキーを使用してログインできます。
個人 SSH キーを使用すると、以下のような利点があります。
+ インスタンスでキーを手動で設定する必要はありません。 OpsWorks スタックはすべてのインスタンスに適切なパブリックキーを自動的にインストールします。
+ OpsWorks スタックは、承認されたユーザーの個人パブリックキーのみをインストールします。
承認されていないユーザーは個人プライベートキーを使用してインスタンスにアクセスすることはできません。Amazon EC2 キーペアを使用すると、対応するプライベートキーを持つすべてユーザーは、SSH アクセス権限の有無にかかわらず、ログインできます。
+ SSH アクセスが不要になったユーザーは、[[**Permissions**] ページ](opsworks-security-users-manage-edit.md)を使用して、ユーザーの SSH/RDP アクセス権限を無効にすることができます。
OpsWorks スタックは、スタックのインスタンスからパブリックキーをすぐにアンインストールします。
+ どの AWS リージョンにも同じキーを使用できます。
ユーザーは、1 個のプライベートキーを管理するだけで済みます。
+ プライベートキーを共有する必要がありません。
各ユーザーが、独自のプライベートキーを使用できます。
+ キーを簡単に更新できます。
管理者またはユーザーが [**My Settings**] でパブリックキーを更新すると、 OpsWorks スタックによってインスタンスが自動的に更新されます。
# Amazon EC2 キーをインストールする
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
スタックを作成する際に、スタック内のすべてのインスタンスにデフォルトでインストールされる Amazon EC2 の SSH キーを指定することができます。
![\[スタック追加ページの Default SSH キーのリスト\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/ec2_keys.png)
**[Default SSH key** (デフォルトのSSHキー)] リストに、AWS アカウントの Amazon EC2 キーが表示されます。次のいずれかを試すことができます。
+ リストから適切なキーを選択します。
+ キーを指定しない場合は、[**Do not use a default SSH key**] を選択します。
[**Do not use a default SSH key**] を選択した場合、またはスタックのデフォルトのキーを上書きする場合は、インスタンスの作成時にキーを指定できます。
![\[SSH キーの指定\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/instance_keys.png)
インスタンスを起動すると OpsWorks 、 スタックはパブリックキーを `authorized_keys` ファイルにインストールします。
# ユーザーのパブリック SSH キーの登録
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
ユーザーのパブリック SSH キーを登録するには、次の 2 つの方法があります。
+ 管理ユーザーが、1 人または複数のユーザーにパブリック SSH キーを割り当て、そのユーザーに対応するプライベートキーを提供します。
+ 管理ユーザーが、1 人または複数のユーザーの自己管理機能を有効にします。
その後、これらのユーザーは自身のパブリック SSH キーを指定できるようになります。
自己管理機能を有効にする方法や、管理ユーザーが他のユーザーにパブリックキーを割り当てる方法の詳細については、「[ユーザー設定の編集](opsworks-security-users-manage-edit.md)」を参照してください。
PuTTY 端末で SSH を使用して Linux ベースのインスタンスに接続するには、追加ステップが必要です。詳細については、AWS ドキュメントの「[PuTTY を使用した Windows から Linux インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html)」および「[インスタンスへの接続に関するトラブルシューティング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html)」を参照してください。
以下に説明しているのは、自己管理機能が有効化された ユーザーがパブリックキーを指定する方法です。
**SSH パブリックキーを指定するには**
1. SSH キーペア を作成します。
最も簡単なアプローチは、キーペアをローカルに生成する方法です。詳細については、「[独自のキーを作成して Amazon EC2 にインポートする方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/generating-a-keypair.html#how-to-generate-your-own-key-and-import-it-to-aws)」を参照してください。
**注記**
PuTTYgen を使用してキーペアを生成する場合は、パブリックキーから**パブリックキーをコピーして OpenSSH authorized\$1keys ファイルボックスに貼り付け**ます。[**Save Public Key**] をクリックすると、パブリックキーは MindTerm でサポートされない形式で保存されます。
1. 自己管理が有効になっている IAM ユーザーとして OpsWorks スタックコンソールにサインインします。
**重要**
アカウント所有者として、または自己管理が有効になっていない IAM ユーザーとしてサインインした場合、 OpsWorks スタックには**マイ設定**が表示されません。管理ユーザーまたはアカウント所有者である場合は、代わりに [**Users**] ページに移動して[ユーザー設定を編集する](opsworks-security-users-manage-edit.md)ことで、SSH キーを指定できます。
1. **自分の設定** を選択すると、サインインしている ユーザーの設定が表示されます。
![\[OpsWorks ダッシュボードの [My Settings] リンク\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/permissions-mysettings-link.png)
1. [**My Settings**] ページで、[**Edit**] をクリックします。
![\[[My Settings] ページの [Edit] ボタン\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/mysettings-editbutton.png)
1. [**Public SSH Key**] ボックスで、SSH パブリックキーを入力し、[**Save**] をクリックします。
![\[[My Settings] ページの [Public SSH Key] ボックス\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/mysettings-setsshkey.png)
**重要**
組み込みの MindTerm SSH クライアントを使用して Amazon EC2 インスタンスに接続するには、ユーザーは IAM ユーザーとしてサインインし、パブリック SSH キーを OpsWorks スタックに登録する必要があります。詳細については、「[組み込みの MindTerm SSH クライアントの使用](workinginstances-ssh-mindterm.md)」を参照してください。
# Linux セキュリティ更新の管理
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
## セキュリティの更新
Linux オペレーティングシステムのプロバイダーは定期的な更新を提供し、その多くがオペレーティングシステムのセキュリティパッチですが、中にはインストールされているパッケージに対する更新も含まれます。インスタンスのオペレーティングシステムは、最新のセキュリティパッチで最新の状態にする必要があります。
デフォルトでは、 OpsWorks スタックはインスタンスの起動が完了した後、セットアップ中に最新の更新を自動的にインストールします。 OpsWorks スタックは、アプリケーションサーバーの再起動などの中断を避けるため、インスタンスのオンライン後に更新を自動的にインストールしません。代わりに、中断の可能性を最小限に抑えるため、オンラインインスタンスへの更新はユーザーが自身で管理します。
次のいずれかの方法を使用して、オンラインインスタンスを更新することをお勧めします。
+ 新しいインスタンスを作成して、現在のオンラインインスタンスを置き換えます。次に、現在のインスタンスを削除します。
新しいインスタンスに、セットアップ時にインストールされたセキュリティパッチの最新のセットが適用されます。
+ Chef 11.10 以前のスタックの Linux ベースのインスタンスでは、[Update Dependencies スタックコマンド](workingstacks-commands.md)を実行します。このコマンドは指定したインスタンスに、セキュリティパッチの現在のセットと他の更新をインストールします。
これらのアプローチの両方で、 OpsWorks Stacks は `yum update` Amazon Linux および Red Hat Enterprise Linux (RHEL) または Ubuntu `apt-get update`に対して を実行して更新を実行します。それぞれのディストリビューションで更新の処理方法は若干異なるため、更新がインスタンスにどのような影響を及ぼすか正確に把握するため、関連リンクの情報を確認してください。
+ **[Amazon Linux** (Amazon Linux)] – Amazon Linux は、セキュリティパッチ更新のほか、パッケージ更新など、機能の更新をインストールします。
詳細については、「[Amazon Linux AMI に関するよくある質問](https://aws.amazon.com/amazon-linux-ami/faqs/#lock)」を参照してください。
+ **[Ubuntu** (Ubuntu)] – Ubuntu では主にセキュリティパッチのインストールに限定されますが、制限された数の重要な修正でパッケージ更新をインストールします。
詳細については、[Ubuntu Wiki の LTS に関するページ](https://wiki.ubuntu.com/LTS)を参照してください。
+ **CentOS** – CentOS の更新では、一般的に前のバージョンとのバイナリ互換性が維持されます。
+ **RHEL** – RHEL の更新では、一般的に前のバージョンとのバイナリ互換性が維持されます。
詳細については、「[Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/)」を参照してください。
特定のパッケージバージョンの指定など、より細かく更新を管理する場合は、[[CreateInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateInstance.html) (インスタンスの作成)]、[[UpdateInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateInstance.html) (インスタンスの更新)]、[[CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html) (レイヤーの作成)]、または [[UpdateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateLayer.html) (レイヤーの更新)] アクション (または同等の [[AWS SDK](https://aws.amazon.com/tools/) (AWS SDK)] メソッド、[[AWS CLI](https://aws.amazon.com/documentation/cli/) (AWS CLI)] コマンド) を使用して自動更新を無効にして、`InstallUpdatesOnBoot` パラメータを `false` に設定します。次の例に、AWS CLI を使用して、既存のレイヤーのデフォルト設定として `InstallUpdatesOnBoot` を無効にする方法を示します。
```
aws opsworks update-layer --layer-id layer ID --no-install-updates-on-boot
```
その後、更新を自身で管理する必要があります。たとえば、次のいずれかの方法を使用できます。
+ [適切なシェルコマンドを実行](cookbooks-101-basics-commands.md#cookbooks-101-basics-commands-script)するカスタムレシピを実装して、希望の更新をインストールします。
システムの更新は[ライフサイクルイベント](workingcookbook-events.md)とは本質的に無関係であるため、カスタムクックブックにレシピを含めて、それを[手動で実行](workingcookbook-manual.md)します。パッケージ更新の場合、シェルコマンドの代わりに、[yum\$1package](https://docs.chef.io/chef/resources.html#yum-package) (Amazon Linux) または [apt\$1package](https://docs.chef.io/chef/resources.html#apt-package) (Ubuntu) リソースを使用することもできます。
+ [SSH で各インスタンスにログイン](workinginstances-ssh.md)し、適切なコマンドを手動で実行してください。
# セキュリティグループの使用
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
## セキュリティグループ
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
各 Amazon EC2 インスタンスには、むしろファイアウォールに近い、インスタンスのネットワークトラフィックを管理する 1 つ以上の関連付けられたセキュリティグループがあります。セキュリティグループには 1 つ以上の*ルール*があり、各ルールでは許可するトラフィックの特定のカテゴリが指定されます。ルールでは、以下を指定します。
+ 許可するトラフィックのタイプ (SSH、HTTP など)
+ トラフィックのプロトコル (TCP、UDP など)
+ トラフィックの発信元の IP アドレスの範囲
+ トラフィックの許可するポート範囲
セキュリティグループには、次の 2 種類のルールがあります。
+ 着信ネットワークトラフィックを規定するインバウンドルール。
たとえば一般的に、アプリケーションサーバーのインスタンスには、IP アドレスからポート 80 へのインバウンド HTTP トラフィックを許可するインバウンドルールと、特定の一連の IP アドレスからのポート 22 へのインバウンド SSH トラフィックを許可する別のインバウンドルールがあります。
+ アウトバウンドルールは、アウトバウンドネットワークトラフィックを規定します。
一般的な方法としては、アウトバウンドトラフィックを許可するデフォルト設定を使用します。
セキュリティグループの詳細については、[「Amazon EC2 Security Groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) (Amazon EC2 セキュリティグループ)」を参照してください。
リージョンで初めてスタックを作成すると、 OpsWorks Stacks は適切なルールセットを持つ各レイヤーの組み込みセキュリティグループを作成します。すべてのグループには、すべてのアウトバウンドトラフィックを許可するデフォルトのアウトバウンドルールが設定されます。一般的に、インバウンドルールは以下を許可します。
+ 適切な スタックレイヤーからのインバウンド TCP、UDP、ICMP OpsWorks トラフィック
+ ポート 22 のインバウンド TCP トラフィック (SSH ログイン)
**警告**
デフォルトのセキュリティグループの設定では、任意のネットワークの場所 (0.0.0.0/0) に対して SSH (ポート 22) が開かれます。これにより、すべての IP アドレスからの SSH によるインスタンスへのアクセスが許可されます。実稼働環境では、特定の IP アドレスまたはアドレス範囲からの SSH によるアクセスのみを許可する設定を使用する必要があります。デフォルトのセキュリティグループを作成直後に更新するか、カスタムセキュリティグループを使用します。
+ ウェブサーバーレイヤーの場合、ポート 80 (HTTP) および 443 (HTTPS) へのすべてのインバウンド TCP および UDP トラフィック
**注記**
組み込みの `AWS-OpsWorks-RDP-Server` セキュリティグループは、RDP アクセスを許可するため、すべての Windows インスタンスに割り当てられます。ただし、デフォルトではルールが何もありません。Windows スタックを実行しており、RDP を使用してインスタンスにアクセスする場合、RDP アクセスを許可するインバウンドルールを追加する必要があります。詳細については、「[RDP でのログイン](workinginstances-rdp.md)」を参照してください。
各グループの詳細については、[[Amazon EC2 console](https://console.aws.amazon.com/ec2/) (Amazon EC2 コンソール)] に移動し、ナビゲーションペインで **[Security Groups** (セキュリティグループ)] を選択して、適切なレイヤーのセキュリティグループを選択します。たとえば、**AWS-OpsWorks-Default-Server** はすべてのスタックの組み込みのデフォルトセキュリティグループで、**AWS-OpsWorks-WebApp** は Chef 12 のサンプルスタックの組み込みのデフォルトセキュリティグループです。
**注記**
OpsWorks スタックセキュリティグループを誤って削除した場合、再作成するには OpsWorks 、スタックにタスクを実行させることをお勧めします。同じ AWS リージョンに新しいスタックを作成するだけで、VPC が存在する場合は、削除したセキュリティグループを含むすべての組み込みセキュリティグループ OpsWorks が自動的に再作成されます。その後、今後使用しないスタックを削除します。セキュリティグループは残ります。セキュリティグループを手動で再作成する場合は、グループ名の大文字と小文字の設定を含め、元のセキュリティグループとまったく同じである必要があります。
さらに、以下のいずれかが発生した場合、 OpsWorks スタックはすべての組み込みセキュリティグループの再作成を試みます。
スタックコンソールで OpsWorks スタックの設定ページに変更を加えます。
スタックのインスタンスの 1 つを起動する。
新しいスタックを作成する。
セキュリティグループを指定するには、次のいずれかの方法を使用できます。[**Use OpsWorks security groups**] 設定を使用して、スタックの作成時に独自の設定を指定します。
+ **はい** (デフォルト設定) – OpsWorks スタックは、適切な組み込みセキュリティグループを各レイヤーに自動的に関連付けます。
レイヤーの組み込みセキュリティグループを微調整するには、必要な設定を指定してカスタムセキュリティグループを追加します。ただし、Amazon EC2 で複数のセキュリティグループを評価するときに最も制限が緩いルールが使用されるため、この方法を使用して、組み込みのグループより厳しいルールを指定することはできません。
+ **いいえ** – OpsWorks スタックは組み込みのセキュリティグループをレイヤーに関連付けません。
適切なセキュリティグループを作成し、1 つ以上のそのグループを作成した各レイヤーと関連付ける必要があります。この方法は、組み込みのグループより厳しいルールを指定する場合に使用します。必要に応じて、組み込みセキュリティグループとレイヤーを手動で関連付けることもできます。カスタムセキュリティグループは、カスタム設定を必要とするレイヤーにのみ必要です。
**重要**
組み込みのセキュリティグループを使用する場合、グループの設定を手動で変更して、より厳しいルールを作成することはできません。スタックを作成するたびに、 OpsWorks スタックは組み込みのセキュリティグループの設定を上書きするため、次回スタックを作成するときに行った変更は失われます。レイヤーで組み込みのセキュリティグループよりも制限の厳しいセキュリティグループの設定が必要な場合は、**[Use OpsWorks security groups] **を **[No]** に設定して、目的の設定でカスタムセキュリティグループを作成し、作成時にレイヤーに割り当てます。