翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# IAM セキュリティのベストプラクティス
IAM 管理者は、次の 3 つの主要分野を担当します。
+ SAP システムが Amazon EC2 メタデータまたはシークレットキー認証情報を使用して自身を認証できることを確認します。
+ SAP システムが `sts:assumeRole` を使用して自身を昇格させるのに必要な権限を持っていることを確認します。
+ 論理 IAM ロールごとに、ビジネス機能の実行に必要な権限 (Amazon S3、DynamoDB、またはその他のサービスに必要な権限など) を持つ SAP ユーザー用の IAM ロールを作成します。これらは、SAP ユーザーが引き受けるロールです。
詳細については、「SAP Lens: AWS Well-Architected フレームワーク」の「[セキュリティ](https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/security.html)」の章を参照してください。
**Topics**
+ [Amazon EC2 インスタンスプロファイルのベストプラクティス](#best-practice-instance-profile)
+ [SAP ユーザーの IAM ロール](#iam-roles-sap-users)
+ [ソースプロファイルのセキュリティに関する考慮事項](#source-profile-security)
## Amazon EC2 インスタンスプロファイルのベストプラクティス
SAP システムが稼働する Amazon EC2 インスタンスには、そのインスタンスプロファイルに基づく一連の認証があります。一般的に、インスタンスプロファイルに必要なのは `sts:assumeRole` を呼び出す権限だけで、SAP システムが必要に応じてビジネス固有の IAM ロールを引き受けることができます。このように他のロールに昇格することで、ABAP プログラムは、その業務に必要な最小特権をユーザーに与えるロールを引き受けることができるようになります。例えば、インスタンスプロファイルには次のステートメントが含まれる場合があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource":[
"arn:aws:iam::012345678912:role/finance-cfo",
"arn:aws:iam::012345678912:role/finance-auditor",
"arn:aws:iam::012345678912:role/finance-reporting"
]
}
]
}
```
------
前の例では、SAP システムが CFO、監査者、または REPORTING ユーザーの IAM ロールを引き受けることを許可します。 AWS SDK は SAP のユーザーの PFCG ロールに基づいて、ユーザーの正しい IAM ロールを選択します。
Amazon EC2 インスタンスプロファイルは他の機能にも使用できます。
+ [AWS SAP HANA 用 Backint エージェント](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html)
+ [オーバーレイ IP アドレスルーティングによる SAP on AWS の高可用性](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-ha-overlay-ip.html)
これらのソリューションでは、バックアップやフェイルオーバーに固有のロールに対する `sts:assumeRole` 権限が必要な場合もあれば、インスタンスプロファイルに直接権限を割り当てる必要がある場合もあります。
## SAP ユーザーの IAM ロール
ABAP プログラムには、ユーザーのジョブを実行するためのアクセス許可が必要です。DynamoDB テーブルを読み取る、Amazon S3 の PDF オブジェクトで Amazon Textract を呼び出す、 AWS Lambda 関数を実行します。すべての AWS SDKs で同じセキュリティモデルが使用されます。別の AWS SDK で使用されていた既存の IAM ロールを使用できます。
SAP ビジネスアナリストは、必要な論理ロールごとに IAM ロールの arn:aws: を IAM 管理者に依頼します。例えば、財務シナリオでは、ビジネスアナリストが以下の論理 IAM ロールを定義する場合があります。
+ `CFO`
+ `AUDITOR`
+ `REPORTING`
IAM 管理者は論理 IAM ロールごとに IAM ロールを定義します。
`CFO`
+ `arn:aws:iam::0123456789:role/finance-cfo`
+ Amazon S3 バケットへの読み取りおよび書き込みアクセス許可
+ DynamoDB データベースへの読み取りおよび書き込みアクセス許可
`AUDITOR`
+ `arn:aws:iam::0123456789:role/finance-auditor`
+ Amazon S3 バケットへの読み取りアクセス許可
+ DynamoDB データベースへの読み取りアクセス許可
`REPORTING`
+ `arn:aws:iam::0123456789:role/finance-reporting`
+ DynamoDB データベースへの読み取りアクセス許可
+ Amazon S3 バケットのアクセス許可なし
ビジネスアナリストは IAM ロールをマッピングテーブルに入力し、論理 IAM ロールを物理 IAM ロールにマッピングします。
SAP ユーザーの IAM ロールでは、信頼できるプリンシパルに `sts:assumeRole` アクションを許可する必要があります。信頼できるプリンシパルは、 AWSでの SAP システムの認証方法によって異なる場合があります。詳細については、「[プリンシパルの指定](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#Principal_specifying)」を参照してください。
以下に、最も一般的な SAP シナリオの例をいくつか示します。
+ **Amazon EC2 上で実行され、インスタンスプロファイルが割り当てられている SAP システム** — ここでは、Amazon EC2 インスタンスプロファイルが IAM ロールにアタッチされます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/SapInstanceProfile"
}
}
]
}
```
------
+ **Amazon EC2 上で実行され、インスタンスプロファイルがない SAP システム** — ここでは、Amazon EC2 が SAP ユーザーのロールを引き継ぎます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [ "ec2.amazonaws.com" ]
}
}
]
}
```
------
+ **オンプレミスで稼働する SAP システム** — オンプレミスで稼働する SAP システムは、シークレットアクセスキーを使用してのみ認証できます。詳細については、「[AWSでの SAP システム認証](https://docs.aws.amazon.com/sdk-for-sapabap/latest/developer-guide/system-authentication.html)」を参照してください。
この場合、SAP ユーザーが引き受けるすべての IAM ロールには、その SAP ユーザーを信頼する信頼関係が必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/SAP_SYSTEM_S4H"
}
}
]
}
```
------
## ソースプロファイルのセキュリティに関する考慮事項
ソースプロファイルを使用する場合:
### IAM ロールの管理
**重要**: ソースプロファイルチェーンの IAM ロールは、不正アクセスと特権のエスカレーションを防ぐために厳密に管理する必要があります。
+ **最小特権の原則を適用する** - 各ロールの特定の目的に必要な最小限のアクセス許可のみを付与します
+ **ロールのアクセス許可を定期的に監査**する - ロールポリシーを四半期ごと、または要件が変更されたときに確認および更新する
+ **ロール使用状況のモニタリング** - を使用して AssumeRole API コールを追跡し、異常なパターンを特定します。
+ **信頼関係の制限** - どのプリンシパルが各ロールを引き受けることができるかを、絶対にアクセスを必要とするプリンシパルのみに制限します。
+ **信頼ポリシーで条件を使用する** - 必要に応じて、ソース IP、MFA 要件、時間ベースの制限などの条件を追加します。
+ **ロールの目的を文書化する** - 各ロールの目的とするユースケースと必要なアクセス許可を明確に文書化します。
### 認可とアクセスコントロール
+ チェーン内のすべての中間プロファイルに適切な信頼ポリシーが設定されていることを確認します。
+ ユーザーは、中間プロファイルを含むチェーン内のすべてのプロファイルに対する`/AWS1/SESS`認可が必要です
+ 各 IAM ロールは、チェーン内の以前のロールを明示的に信頼する必要があります
### 技術的な保護
+ SDK は、過剰な STS API コールを防ぐために、最大チェーン深度 5 プロファイルを適用します。
+ 循環参照は自動的に検出され、防止されます
+ ベースプロファイル認証方法が検証され、標準メソッド (INST、SSF、または RLA) が使用されていることを確認します。
ソースプロファイルの設定の詳細については、[「クロスアカウントアクセスでのソースプロファイルの使用](https://docs.aws.amazon.com/sdk-for-sapabap/latest/developer-guide/source-profile.html)」を参照してください。