カテゴリー: AWS Certified Security – Specialty

  • kms:ViaService の考え方について

    kms:ViaService を利用して、CMK を呼び出していない時」というポリシーの書き方をすることができる

                    "Null": {
                        "kms:ViaService": "true"
                    },
    

    この部分は Classmethod さんのブログが非常にわかりやすい

    https://dev.classmethod.jp/articles/ebs-kms-sourceip/

    kms:ViaServiceは、CMKの使用を指定のAWSサービスからのリクエストに制限する条件キーであり、

    Nullは、条件キーの存在を確認する条件演算子を指す。

    Nullで {"kms:ViaService": "true"}と指定すると、「kms:ViaServiceが存在しない(≒CMKを呼び出していない)」という条件になる。

    これを接続元IPアドレスを制限する条件に追加することで、「CMKを呼び出していない かつ 接続元IPを制限する」という条件になる。

  • AWS Inspector と AWS Trusted Advisor について

    あまり日常的に触らないサービスの1つである。

    何度もこの違いについて過去に調べてはいたが、使わないものは忘れてしまう。

    メモがてら残す。

    AWS Inspector とは

    https://aws.amazon.com/jp/inspector/

    EC2 インスタンス上の脆弱性をチェック ができると考えて良さそうだ。

    また、脆弱性チェック対象のインスタンスは、エージェントをインストールする必要がある。

    AWS Trusted Advisor とは

    https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/

    こちらはエージェントのインストール不要。

    インスタンスをスキャンし、AWS のベストプラクティスを元に、
    • コストの最適化
    • セキュリティ
    • 耐障害性
    • パフォーマンス
    • サービスの制限

    の5つの項目について、チェックすることが出来るツール。

    まとめ

    それぞれ1行でまとめると

    AWS Inspector は脆弱性検知することが必要でエージェントが必須

    AWS Trusted Advisor は AWS のベストプラクティスに沿って作られているかスキャン、レポーティングしてくれる機能

    と考えておけば良さそうだ

  • S3バケットアクションはどのリソースにも適用されません

    {
      "Id": "xxxxx",
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "xxxxx",
          "Action": [
            "s3:GetObject"
          ],
          "Effect": "Allow",
          "Resource": "arn:aws:s3:::hoge-hoge",
          "Principal": "*"
        }
      ]
    }
    

    この設定をしていて アクションはステートメント内のどのリソースにも適用されません とエラーが出る

    原因は、バケットのみ Resource として指定しているためであり、この問題を解消するには

          "Resource": "arn:aws:s3:::hoge-hoge/*",
    

    のようにバケット内のどのオブジェクトにアクセスを許可するかを必ず指定する必要がある。

  • CMK キーの自動キーローテーション間隔について

    AWS 管理のCMK は我々ユーザーで管理することはできないが、 3年ごとに自動でローテーションされる

    AWS 管理の CMK AWS 管理の CMK のキーローテーションを管理することはできません。AWS KMS は AWS 管理の CMK を 3 年ごと (1095 日) に自動的にローテーションします。

    https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/rotate-keys.html

    なお、我々ユーザーが管理する CMK は 365 日に設定されている

    キーの自動ローテーションを有効にすると、AWS KMS は有効にした日から CMK を 365 日ローテーションし、その後は 365 日ごとにローテーションします。

    https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/rotate-keys.html

  • 利用しているAWS リソースを確認する

    監査などを目的とし、どのリソースをどれだけ使われているか確認したいことがあるが、

    それを確認するには AWS config が便利なので紹介。

    とはいえ AWS config からリソースを選択するだけ。

    使っていないと思っていたものが、実は使っていたといったケースもこれで確認できる。
  • S3 の CORS について

    s3 は通常、静的ウエブサイトをホストすることができるが、JavaScript 経由で バケットに対する GET/POST を行う際は注意が必要である。

    よくある事例

    S3 に hoge.com という名前でホストしたとする。

    このバケットに保存されている JavaScript によって、S3 のエンドポイントである hoge.s3.ap-northeast-1.amazonaws.com に GET/POST を行おうとすると、

    ブラウザは通常、別ドメインに対する接続しようとする JavaScript をブロックする。

    CORS を使用すると、hoge.com からのクロスオリジンリクエストを許可できるようにバケットを設定することができる。

    参考情報

    https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html

  • AWS コンソールログイン時の他要素認証

    カスタムIAM ポリシーを設定することで、MFA を有効化することができる。

        "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    

    ポイントは、

    Conditiol 文を使用すると、ユーザーが MFA 認証されている場合にのみリソースを操作できるようになる。

    aws:MultiFactorAuthPresent 句を true としてマークする必要がある。

    参考情報

    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html