初めまして、つかさです
IT業界で働くようになってから約1年過ぎ、普段はWebエンジニアとして働いてますが、何か次のステップアップをしたいなと思い、とりあえずawsの資格の勉強を始めました!
自分が躓いた箇所や苦手分野などを、記事を通してアウトプットしたいのと同時に、同じ所で躓いている方の参考になればなと思ってます！
よろしくお願いします！
S3
Amazon Simple Storage Serviceの略でデータ保存するサービス
基本構成
- 問題文
- 答え
- なぜその答えなのか
- その答えを理解するための周辺知識
| 問題 | 答え | 理由 |
|---|---|---|
| 特定のS3バッケットのオブジェクトへのアクセスログを1年間保存する要件がある。この期間中は誰でも削除することはできないです。保存方法として最適なものは？ | S3のバージョニングを有効にし、オブジェクトロックのコンプライアンスモードを有効にして1年間保存する。 | 問題文に誰でもとあるので、たとえルートユーザーであっても解除することは出来ないオブジェクトロックのコンプライアンスモードが正解です。 |
この問題でまず押さえないといけないのはバージョニングです。
バージョニング
簡単に言うと、人的ミスでデータが失われたりしないようにバージョン管理しようっていう機能です。
デフォルトでは無効なので、意図的に有効にする必要があります。
例えば誤って上書きした場合、元のバージョンにロールバックする方法としてDeleteObjectVersionアクションがあります。DeleteObjectVersionアクションは、特定のバージョンIDを指定して、そのバージョンのオブジェクトを削除します。よって最新のバージョンを削除することで、ロールバック可能になります。
しかし、DeleteObjectVersionアクションを行えるユーザーが誤って削除してはならないバージョンを消してしまう可能性があります。そんな時に役に立つ機能として以下2つがあります。
- MFA Delete
- オブジェクトロック
オブジェクトロック
オブジェクトロックで設定したオブジェクトは保持期間中DeleteObjectVersionアクションができないようにすることができます。
この機能の中にも3つの使い方があります。
1. ガバナンスモード
2. コンプライアンスモード
3. リーガルホールド
これらの使い方に大きな違いはありません。なので要件によって使い分ける事が大切です!
| 保持期間を設定する | ユーザーによって解除できる | |
|---|---|---|
| ガバナンスモード | ◯ | ◯ |
| コンプライアンスモード | ◯ | × |
| リーガルホールド | × | ◯ |
MFA Delete
ユーザーがDeleteObjectVersionアクションを行う前にMFA認証をするようにする機能です。
| 問題 | 答え | 理由 |
|---|---|---|
| アカウントAのIAMユーザーがアカウントBのS3バケットへのオブジェクトをアプロードする必要がある。どのポリシーが必要ですか？(2つ) | アカウントAのアイデンティティベースのポリシーとアカウントBのS3バケットポリシー | S3に直接アクセスするクロスアカウントアクセスを設定する場合、答え2つのポリシーを設定する必要があります。 |
この問題でのポイントはS3バケットポリシーになります。
S3バケットポリシー
S3はリソースベースのポリシーです。
{
"Version": "2012-10-17",
"Id": "ExamplePolicy",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
}
]
}
| 役割 | |
|---|---|
| Version | ポリシーのバージョンを指定 |
| Id | ポリシーに一意の識別子を割り当てるためのオプションのフィールド |
| Statement | 実際のアクセス許可を定義するフィールド |
さらにStatementフィールドの中に複数のフィールド
| 役割 | |
|---|---|
| Effect | アクションを許可するか拒否するかを指定 値はAllowまたはDeny
|
| Action | 許可または拒否する操作を定義 s3:PutObject,s3:GetObject,s3:ListBucketなど |
| Resource | ポリシーが適用されるリソースを指定 |
| Principal | アクションを許可または拒否するエンティティ（ユーザー、アカウント、ロール）を指定。すべてのユーザーに対して適用する場合は * を使用 |
| Condition | 特定の条件を指定。 例えば、IPアドレス範囲やAWSサービスの特定のリクエストでのみアクセスを許可することができます。 |
| Sid | ステートメントに一意のIDを割り当てるためのフィールド |
今回の問題の場合、ResourceにアカウントAのアイデンティティベースのポリシーに含める対象のリソースを書く。PrincipalにアカウントAを設定することで要件を満たせます。
まとめ
読んでいただきありがとうございました！
これからも自分のペースで記事を更新したり、新たな記事を書いていこうと思うので是非見ていただけたらなと思います！