1 Minute Tips

日: 2021年8月1日

  • AWS Organizations の[組織の証跡]について整理する

    「組織の証跡」とは

    組織内のマスターアカウントとすべてのメンバーアカウントの CloudTrail イベントを同じ

    • Amazon S3 バケット
    • CloudWatch Logs
    • CloudWatch イベント

    に配信できるようにする設定である。

    組織の証跡を作成すると、組織のための統一されたイベントログ記録戦略を定義するのに役立つ。

    組織の証跡を作成すると、自分の組織に属するすべての AWS アカウントに、指定した名前の証跡が作成される。

    メンバーアカウントで CloudTrail アクセス許可を持つユーザーは、

    • AWS アカウントから AWSCloudTrail コンソールにログインしたとき
    • describe-trails などの AWS CLI コマンドを実行したとき

    この証跡 (証跡 ARN を含む) を表示することができる。

    各AWSアカウントでアクティビティが発生すると、そのアクティビティはCloudTrailイベントに記録される。

    イベント履歴に移動すると、CloudTrailコンソールで最近のイベントを簡単に表示できる。

    マルチリージョンおよびグローバルイベントの追跡を有効にすることもできる。

    デフォルトでは、CloudTrailによってバケットに配信されるログファイルは、

    Amazon S3管理の暗号化キー（SSE-S3）を使用したAmazonサーバー側の暗号化によって暗号化される。

    直接管理可能なセキュリティレイヤーを提供するために、

    CloudTrailログファイルにAWS KMS管理キー（SSE-KMS）を使用したサーバーサイド暗号化を使用できる。

    ログを保護するには、S3バケットを暗号化し、バケット作成時にデータ削除不可の設定を行うことで、永続的にログを保存することが可能。

    マスターアカウントに対して単一のCloudTrailを有効化して、ターゲットアカウント設定において他の子アカウントをターゲット設定・・・と言うことは必要ない。

    AWS Organizationsを利用して、CloudTrailの「組織の証跡」を利用することで子アカウントにも自動的にCloudTrailログを設定することが可能になるからだ。

  • IPSec VPN の特徴

    デフォルトで Amazon VPC 内に起動されるインスタンスと、ユーザー独自のネットワークとの通信はできない。

    VPC から独自のネットワークへのアクセスを可能にするには、以下のアプローチが必要になる。

    1. 仮想プライベートゲートウェイを VPC に関連付ける
    2. カスタムルートテーブルを作成
    3. セキュリティグループ規則を更新
    4. AWS Site-to-Site VPN接続を作成する

    Site-to-Site VPN は、インターネットプロトコルセキュリティ (IPsec) VPN 接続をサポートしている。 

    IPSecの特徴

    • Site-to-Site VPN 接続は、AWS Classic VPN または AWS VPN のいずれか。
    • IPSecトンネル経由で送信されるデータの整合性を保持する。
    • IPSecトンネルを経由して送信されるデータは暗号化される。
    • IPSecはインターネット経由で送信中のデータを保護する。
    • IPSecトンネルのセットアップ中にIDが認証される。
    • VPNゲートウェイ（VPG）とカスタマーゲートウェイ（CGW）の間にIPSecトンネルが確立される。

    データは暗号化されるが、SSLを利用してはいるわけではないと言うのは大きな特徴だ。

    参考情報

    IPsec-VPNとは？SSL-VPNとの違いもわかりやすく徹底解説！

    https://it-trend.jp/vpn/article/48-0063

  • AWS Elastic Beanstalk の deploy policy を整理する

    AWS Elastic Beanstalk は、デプロイポリシーも含めデプロイを処理するいくつかのオプションがある。

    All at once

    新しいバージョンをすべてのインスタンスに同時に展開する。

    環境内のすべてのインスタンスは、展開が行われている間、短時間サービスが停止することになる。

    そのため、展開に必要な合計時間を最短にする方法にはなる。

    Rolling

    Elastic Beanstalk は環境の EC2 インスタンスを複数のバッチに分割し、アプリケーションの新しいバージョンを一度に 1 つのバッチにデプロイする。

    そのため、環境内の残りのインスタンスは古いアプリケーションバージョンを実行した状態になる。

    つまりローリングデプロイ中は、アプリケーションの古いバージョンでリクエストを処理するインスタンスもあり、新しいバージョンでリクエストを処理するインスタンスも存在する。

    Rolling with additional batch

    新しいバージョンをバッチで展開するが、最初にインスタンスの新しいバッチを起動して、展開プロセス中に完全な容量を確保する。

    Immutable

    変更不可能な更新を実行して、古いバージョンを起動しているインスタンスと並行しながら、別の Auto Scaling グループにあるアプリケーションの新しいバージョンを起動している新しいインスタンスのフルセットを起動する。

    部分的に完了したローリングデプロイにより発生する問題を防止することができる。

    新しいインスタンスがヘルスチェックをパスしなかった場合、Elastic Beanstalkはそれを終了し、元のインスタンスをそのまま残す。

    参考情報

    https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html

  • AWSアカウントを跨いで S3 などを共有する

    リソースベースポリシーのクロスアカウントアクセスを設定することで対応が可能。

    一部の AWS サービスでは、リソースに対するクロスアカウントアクセス許可を付与することができる。

    クロスアカウントの理論についてはこちら

    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html

    これを行うには、プロキシとしてロールを使用するのではなく、

    共有するリソースに直接ポリシーをアタッチすることになる。

    共有するリソースは、リソースベースのポリシーをサポートしている必要がある。

    なお、リソースベースポリシーが有効になっているサービスは

    • S3
    • SNS
    • SQS

    のみ。

    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_compare-resource-policies.html

    ユーザーベースのポリシーとの違い

    端的に言うと、ユーザーに割り当てるのではなく、サービスに割り当てるもの。

    リソースベースポリシーは Principal が必須となる。

    公式のスライドはこちら

    https://www.slideshare.net/AmazonWebServicesJapan/20150617-aws-blackbeltiam

    公式ドキュメントはちょっと難解なので、Classmethod さんの記事が非常にわかりやすく噛み砕かれていた。

    https://dev.classmethod.jp/articles/aws-iam-policy/

  • Lambda カスタム統合/Lambdaプロキシ統合 について

    API Gateway と Lambdaファンクションを統合して実行するための方法は

    • Lambda カスタム統合
    • Lambdaプロキシ統合

    の２つあるのでそれぞれ整理する

    Lambda カスタム統合

    プロキシ統合のセットアップ手順に加えて、

    受信リクエストデータがどのように統合リクエストにマッピングされるか、
    統合レスポンスデータの結果がメソッドレスポンスにどのようにマッピングされるかを指定す。

    https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/set-up-lambda-custom-integrations.html

    Lambda プロキシ統合

    おそらく、API GW + lambda の構成の場合最も使われている機能だと思う。

    API にコンテンツのエンコーディングやキャッシュが不要な場合は、

    統合の HTTP メソッドを POST に設定し、統合エンドポイント URI を特定の Lambda 関数のアクションを呼び出す Lambda 関数の ARN に設定することで、認証情報を API Gateway がユーザーに代わって Lambda 関数を呼び出すことを許可する。

    https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html

  • AWS OrganizationsのSCP の落とし穴

    概要

    AWS Organizationsのサービスコントロールポリシー (SCP) は、組織を管理するために使用できるポリシーのタイプ。

    特徴

    SCP は、組織内のすべてのアカウントの最大使用アクセス権限を一元的に管理できる機能を提供し、アカウントが組織のアクセスコントロールガイドラインに沿って活動することを確実にする。

    SCP は、すべての機能が有効になっている組織でのみ使用できる。

    SCPはサービスにリンクされたロールには影響しないようになっているという特徴がある。

    IAMロール をインスタンスにアタッチしているなどの場合は、SCPによって制限することはできない。