アーサー・C・ダントー | 伊東屋TECHブログ https://tech-itoya.com 千葉県・船橋市の総合園芸店が運営する技術ブログ Fri, 06 Dec 2024 14:49:24 +0000 ja hourly 1 https://wordpress.org/?v=6.9 https://tech-itoya.com/wp-content/uploads/2024/10/cropped-itoya-logo-32x32.png アーサー・C・ダントー | 伊東屋TECHブログ https://tech-itoya.com 32 32 各リージョンで有効化したGuardDutyの検出結果を管理者に通知する https://tech-itoya.com/%e5%90%84%e3%83%aa%e3%83%bc%e3%82%b8%e3%83%a7%e3%83%b3%e3%81%a7%e6%9c%89%e5%8a%b9%e5%8c%96%e3%81%97%e3%81%9fguardduty%e3%81%ae%e6%a4%9c%e5%87%ba%e7%b5%90%e6%9e%9c%e3%82%92%e7%ae%a1%e7%90%86%e8%80%85/ https://tech-itoya.com/%e5%90%84%e3%83%aa%e3%83%bc%e3%82%b8%e3%83%a7%e3%83%b3%e3%81%a7%e6%9c%89%e5%8a%b9%e5%8c%96%e3%81%97%e3%81%9fguardduty%e3%81%ae%e6%a4%9c%e5%87%ba%e7%b5%90%e6%9e%9c%e3%82%92%e7%ae%a1%e7%90%86%e8%80%85/#respond Fri, 06 Dec 2024 14:33:46 +0000 https://tech-itoya.com/?p=241 こんにちは。ダントーです。

今回は、セキュリティ施策のために東京リージョン以外の各リージョンでGuardDurtyを有効化したけど検出結果をどうやって管理者に通知するかで悩んでいる方向けの記事です。

簡素ではありますが、いくつかある選択肢を比較考量していく中で自分の環境に最適な構成を選ぶ材料となれば幸いです。

では、いきましょう。

想定検索ワード：GuardDuty 検出結果 通知 東京リージョン以外

TL;DR;

1. 可能なオプションについて考える

まずは各リージョンの検出結果を管理者に通知するにあたって、どのようなオプションが可能なのか考えていきます。

① 各リージョンにEventBridgeルールとSNSトピックを作成する

簡単な構成図を書くとこのようになります。

かなり愚直な選択肢ではありますが、構成上の統一感という意味ではこの選択肢も悪くないのかもしれません。

しかし各リージョンにEventBridgeルールやSNSトピックを作る必要があり、またSNSトピックについては都度サブスクライブを行わなくてはいけない点はデメリットとなります。

加えて、検出結果をフィルタリング&整形しようとすると各リージョンのEventBridgeルールに同一設定を入れなくてはいけない点もやや微妙と言えるでしょう。

まとめると…

メリット

  • 構成上の統一感あり
  • 構築自体の難易度は低め(同一設定の繰り返しとなるためとっつきやすい)

デメリット

  • SNSを各リージョンごとにサブスクライブしなくてはいけない
  • リソースの作成が冗長的になる(同一リソース・同一設定の繰り返しとなるため)

② 東京リージョンCustom event busで集約する

先ほどの①のパターンから東京リージョン以外のSNSトピックを削除します。

つまり、全リージョンの検出結果を一度東京リージョンに集約し、東京リージョンのSNSトピックから管理者に通知を行います。

構成図としては以下のようになります。

フローとしては、全リージョン(東京リージョンを含む)での検出結果を東京リージョンのカスタムイベントバスに送信し、カスタムイベントバスに紐づけたルールでファイルタリング&整形を行います。

①と比較すると、東京リージョン以外ではSNSトピックが無くなり、東京リージョンではカスタムイベントバスとフィルタリングルールが増えています。

つまり各リージョンでサブスクライブする必要が無くなった一方で、東京リージョンでは検出結果を集約するカスタムイベントバスとフィルタリング&整形用のルールを作成する必要が生じているということです。

まとめると…

メリット

  • 東京リージョン以外でSNSトピックを作成する必要がない
  • フィルタリング&整形用の同一設定を入れなくて済む

デメリット

  • 構築難易度は低くはない(①と比較してですが)

③ AWS Security Hubのリージョン集約を有効化する

3つ目の選択肢は、AWS Security Hubでのクロスリージョン集約機能を有効化し、各リージョンの検出結果をメインの東京リージョン(=ホームリージョン)に集めるというものです。

構成図は以下のようになります。

Security Hubを使うことで東京リージョン以外にEventBridgeのリソースを作る必要がない点が、これまでの構成とは異なっています。

この場合だと、各リージョンの検出結果を(東京リージョンの)SecurityHubコンソール上から一挙に確認できるという視認性の良さはメリットになるはずです。

一方で、全リージョンでSecurity Hubを有効化しなくてはならないという点はデメリットになるかもしれません。

(これについては、セキュリティ要件として全リージョンですでにSecurity Hubを有効化していた場合はデメリットにはならないでしょう。)

まとめると…

メリット

  • 構築難易度は低い(設定を有効化するだけ)
  • 検出結果の視認性が良い

デメリット

  • 全リージョンでSecurity Hubを有効化する必要がある

以上で、選択肢の比較考量は終わりです。

実装については、また別の機会に記事にしたいと思います。

2. 参考記事

]]> https://tech-itoya.com/%e5%90%84%e3%83%aa%e3%83%bc%e3%82%b8%e3%83%a7%e3%83%b3%e3%81%a7%e6%9c%89%e5%8a%b9%e5%8c%96%e3%81%97%e3%81%9fguardduty%e3%81%ae%e6%a4%9c%e5%87%ba%e7%b5%90%e6%9e%9c%e3%82%92%e7%ae%a1%e7%90%86%e8%80%85/feed/ 0 CloudFormationスタックから外れたサブネットをスタック管理下に引き戻したい https://tech-itoya.com/cloudformation%e3%82%b9%e3%82%bf%e3%83%83%e3%82%af%e3%81%8b%e3%82%89%e5%a4%96%e3%82%8c%e3%81%9f%e3%82%b5%e3%83%96%e3%83%8d%e3%83%83%e3%83%88%e3%82%92%e3%82%b9%e3%82%bf%e3%83%83%e3%82%af%e7%ae%a1/ https://tech-itoya.com/cloudformation%e3%82%b9%e3%82%bf%e3%83%83%e3%82%af%e3%81%8b%e3%82%89%e5%a4%96%e3%82%8c%e3%81%9f%e3%82%b5%e3%83%96%e3%83%8d%e3%83%83%e3%83%88%e3%82%92%e3%82%b9%e3%82%bf%e3%83%83%e3%82%af%e7%ae%a1/#respond Sun, 13 Oct 2024 07:54:09 +0000 https://tech-itoya.com/?p=134 こんにちは。ダントーです。

CloudFormationスタックで管理していたサブネットが、スタックの更新・削除により意図せずスタック管理下から外れてしまって焦っている方向けの記事です。

他リソースが依存しているサブネットをスタックから削除しようとすると、スタックから消えないだけでなくスタック管理下から外れるといった現象に出くわしたので、その際の対応を備忘録として残します。

想定検索ワード：CloudFormation スタック サブネット 外れる

TL; DR;

  1. CloudFormationの既存スタックへのリソースインポート機能を使う
    • スタック管理下から外れたサブネットを既存スタックにインポートします
  2. 本来デプロイするはずのテンプレートを使用して既存スタックを再度更新します
    • 消失したリソースがある場合はこの手順も踏んだほうが良いです

では、いきましょう。

構成図とCloudFormationテンプレート

今回想定している構成です。

ポイントはサブネットの存在に依存するリソースが存在していること、つまりサブネット上にVPC Lambdaがデプロイされている点になります。

また、ネットワーク復旧確認用にVPC EndpointとS3を用意しています。

本題

まずは、今回使用するCloudFormationテンプレートを確認します。

テンプレートはNetwork.yamlとLambda.yamlの2種類です。

Network.yamlでは

  • VPC
  • ルートテーブル
  • サブネット
  • VPCエンドポイント(Gateway)
  • パラメータストア(VPCID)　　　　　　← Lambda.yamlにパラメータを渡すために作成
  • パラメータストア(サブネットID)　　　← Lambda.yamlにパラメータを渡すために作成

これらを作成しています。

また、Lambda.yamlでは、

  • IAMロール
  • セキュリティグループ
  • Lambda関数
  • S3バケット　　　　　　　　　　　　　←ネットワーク疎通確認用

これらを作成しています。

ネットワークの疎通が取れているかを確認するために、Lambda関数内ではS3バケットにファイルをはき出すロジックを入れています。

①正常時、②サブネットをスタックに引き戻したとき

これら2つのケースでネットワークに問題がないことを確認します。

詳細は以下のテンプレートを確認してください。

AWSTemplateFormatVersion: "2010-09-09"
Description: Network

Parameters:
  Prefix:
    Description: Enter Prefix.
    Type: String
    Default: sample

Resources:
#---------------------------------------------------#
# VPC
#---------------------------------------------------#
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      InstanceTenancy: default
      Tags:
        - Key: Name
          Value: !Sub ${Prefix}-vpc

#---------------------------------------------------#
# RouteTable
#---------------------------------------------------#
  PrivateRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: Name
          Value: !Sub ${Prefix}-private-rt

#---------------------------------------------------#
# Subnet1A and RouteTableAssociation
#---------------------------------------------------#
  PrivateSubnet1A:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: 10.0.16.0/20
      AvailabilityZone: !Select
        - 0
        - Fn::GetAZs: !Ref AWS::Region
      Tags:
        - Key: Name
          Value: !Sub ${Prefix}-private-subnet-1a

  PrivateSubnet1ARouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PrivateRouteTable
      SubnetId: !Ref PrivateSubnet1A

#---------------------------------------------------#
# S3 VPCEndpoint
#---------------------------------------------------#
  RecoveryS3VPCEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
      VpcEndpointType: Gateway
      VpcId: !Ref VPC
      RouteTableIds:
        - !Ref PrivateRouteTable

#---------------------------------------------------#
# Parameters Section
#---------------------------------------------------#
  ParamRecoveryVPCId:
    Type: AWS::SSM::Parameter
    Properties:
      Name: /Network/VPCId
      Type: String
      Value: !Ref VPC

  ParamPrivateSubnet1AId:
    Type: AWS::SSM::Parameter
    Properties:
      Name: /Network/PrivateSubnet1AId
      Type: String
      Value: !Ref PrivateSubnet1A

AWSTemplateFormatVersion: "2010-09-09"
Description: Lambda

Parameters:
  Prefix:
    Description: Enter Prefix.
    Type: String
    Default: sample

  ParamVPCId:
    Type: AWS::SSM::Parameter::Value<String>
    Default: /Network/VPCId

  ParamPrivate1ASubnetId:
    Type: AWS::SSM::Parameter::Value<String>
    Default: /Network/PrivateSubnet1AId

Resources:
#---------------------------------------------------#
# IAM Role for Lambda Function
#---------------------------------------------------#
  LambdaFunctionRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Sub ${Prefix}-lambda-role
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - lambda.amazonaws.com
            Action:
              - 'sts:AssumeRole'
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole
        - arn:aws:iam::aws:policy/AmazonS3FullAccess

#---------------------------------------------------#
# SecurityGroup for Lambda Function
#---------------------------------------------------#
  LambdaSG:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: for lambda
      GroupName: !Sub ${Prefix}-lambda-sg
      VpcId: !Ref ParamVPCId

  LambdaSGEgressToANY:
    Type: AWS::EC2::SecurityGroupEgress
    Properties:
         IpProtocol: -1
         CidrIp: 0.0.0.0/0
         GroupId: !Ref LambdaSG

#---------------------------------------------------#
# Lambda Function
#---------------------------------------------------#
  LambdaFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: !Sub ${Prefix}-function
      Role: !GetAtt LambdaFunctionRole.Arn
      Runtime: python3.10
      Handler: index.lambda_handler
      Code:
        ZipFile: |
          import json
          import boto3
          from datetime import datetime
          
          def lambda_handler(event, context):
              s3 = boto3.client('s3')
              bucket_name = 'sample-check-network-status-bucket'
              current_time = datetime.now().strftime('%Y%m%d_%H%M%S')
              file_name = f'trial_{current_time}.txt'
              file_content = 'Hello World!'
              
              s3.put_object(Bucket=bucket_name, Key=file_name, Body=file_content)
              return {
                  'statusCode': 200,
                  'body': json.dumps('Hello from Lambda!')
              }
      VpcConfig:
        SecurityGroupIds:
          - !Ref LambdaSG
        SubnetIds:
          - !Ref ParamPrivate1ASubnetId
      Timeout: 10

#---------------------------------------------------#
# S3 Bucket for checking the network status
#---------------------------------------------------#
  AssetsBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub ${Prefix}-check-network-status-bucket
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      VersioningConfiguration:
        Status: Suspended

状況を再現(スタックを作成する)

ここでは、CloudShellからスタック作成を実施します。

(破壊した環境にもよりますが、おそらく通常では開発環境等で復旧テスト→当該環境で復旧作業となると想定しています。その際に余計な環境差を出さないためにもCloudShellからの実行としています。)

2つのスタックには依存関係があるので、Network.yaml → Lambda.yamlの順でデプロイしていきます。

ファイルをCloudShellにアップロードした後、以下のコマンドを実行します。

# 1. ネットワークスタックを作成
aws cloudformation deploy \
    --template-file Network.yaml \
    --stack-name  sample-network-stack

# 2. Lambdaスタックを作成
aws cloudformation deploy \
    --template-file Lambda.yaml \
    --stack-name  sample-lambda-stack \
    --capabilities CAPABILITY_NAMED_IAM

# 3. ネットワークスタックの管理下にあるリソースを確認
aws cloudformation describe-stack-resources \
    --stack-name sample-network-stack \
    --query "join(', ', StackResources[*].LogicalResourceId)" --output text \
    --output text

3の実行結果は以下となります。

また、Lambda関数を実行してS3バケットにファイルが出力できることも確認しておきます。

# 1. S3バケット内のオブジェクト数を確認
#    → 「Total Objects: 0」と表示される
aws s3 ls s3://sample-check-network-status-bucket \
    --recursive \
    --summarize

# 2. Lambda関数を実行
aws lambda invoke \
    --function-name sample-function \
    outputfile.txt

# 3. S3バケット内のオブジェクト数を確認
#    → 「Total Objects: 1」と表示される
aws s3 ls s3://sample-check-network-status-bucket\
    --recursive \
    --summarize

ここまででスタックの作成はOKです。

状況を再現(スタック管理下からサブネットを外す)

では、ここからはサブネットをスタック管理下から外していきます。

Network.yaml内の記述を修正したDestructive-Network.yamlを用意して、既存のスタックを上書きしましょう。

Destructive-Network.yamlで作成予定のリソースは以下です。

  • VPC
  • ルートテーブル

サブネットを削除しているのがポイントです。

AWSTemplateFormatVersion: "2010-09-09"
Description: Network

Parameters:
  Prefix:
    Description: Enter Prefix.
    Type: String
    Default: sample

Resources:
#---------------------------------------------------#
# VPC
#---------------------------------------------------#
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      InstanceTenancy: default
      Tags:
        - Key: Name
          Value: !Sub ${Prefix}-vpc

#---------------------------------------------------#
# RouteTable
#---------------------------------------------------#
  PrivateRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: Name
          Value: !Sub ${Prefix}-private-rt

ではこのテンプレートをCloudShellにアップロードして、デプロイしちゃいます。

aws cloudformation deploy \
    --template-file Destructive-Network.yaml \
    --stack-name  sample-network-stack

1時間程度経過した後にコンソール画面を確認すると、サブネットの依存関係の問題で数回DELETE_FAILEDとなり、最終的にエラー文は出力されていはいるもののUPDATE_COMPLETEステータスとなっています。

# DELETE_FAILED時のエラー文
Resource handler returned message: "The subnet 'subnet-0dxxxxxxxxxxxxx25' has dependencies and cannot be deleted.

# UPDATE_COMPLETE時の文
Update successful. One or more resources could not be deleted.

ここで、ネットワークスタック管理下にあったサブネットの状況を確認します。

# 1. ネットワークスタックの管理下にあるリソースを確認
aws cloudformation describe-stack-resources \
    --stack-name sample-network-stack \
    --query "join(', ', StackResources[*].LogicalResourceId)" --output text \
    --output text

# 2. Nameを指定して、既存のサブネットから対象のサブネットの情報を表示
aws ec2 describe-subnets \
    --query "Subnets[?Tags[?Key=='Name' && Value=='sample-private-subnet-1a']]"

1の実行結果は以下です。

サブネットはスタック管理下にはいないことが伺えます。

また一方で、2の結果からはサブネットは削除されず環境上に存在しており、たんにスタックから外れているだけだと推測できます。

この状況ですと、今後の運用でNetwork.yamlテンプレート内でサブネットのID等を利用したい場合には値をべた書きすることになります。仮にこのテンプレートを1環境だけで利用する場合はこれでも構いませんが、複数環境で利用している場合には!Ref等で値を渡せないのはかなり厳しいです。

そのため、再度サブネットをスタック管理下に引き戻し、元の状態へ戻す必要がでてくるはずです。

本題：サブネットをスタック管理下に引き戻す

サブネットをスタック管理下に引き戻すためには、既存スタック(sample-network-stack)に対象のサブネットをインポートします。

既存スタックへのインポート機能の詳細については、以下の公式ドキュメントを参照ください。

スタックへの既存リソースのインポート – AWS CloudFormation (amazon.com)

では、順を追ってインポートを実行していきましょう。

1. インポート時の設定ファイルを作成する

インポートコマンド実行時に必要になる設定ファイルを組み立てていきます。

[
    {
        "ResourceType": "AWS::EC2::Subnet",
        "LogicalResourceId": "PrivateSubnet1A",
        "ResourceIdentifier": {
            "SubnetId":"subnet-0dxxxxxxxxxxxxx25"
        }
    }
]

各種キーについて簡単に説明します。

  • ResourceType
    • インポート対象のリソースタイプを指定する
  • LogicalResourceId
    • インポート時に読み込ませるCloudFormationテンプレート上で、インポート対象のリソースに割り当てる論理IDを指定する
    • この記事では最終的に元のNetwork.yamlで上書きするため、そこで使用していた論理IDを使っています
  • ResourceIdentifier
    • インポート対象リソース識別子を指定する

また、それぞれのキーに何を指定すればよいか(ここではSubnetId)は、get-tempate-summeryコマンドで大まかに調査可能です。

aws cloudformation get-template-summary \
    --template-body file://./Network.yaml \
    --query 'ResourceIdentifierSummaries'

2. インポート用のCloudFormationテンプレートを作成する

ここでは、現在デプロイされているCloudFormationテンプレートにインポート対象とするサブネットを追記したものを作成します。

次の2点に注意してください。

  • 既存リソースの設定値は変更しない
  • インポート対象のリソースには、DeletionPolicyとUpdateReplacePolicyを追記する

※その他の削除済みリソースは後ほど再作成します。

AWSTemplateFormatVersion: "2010-09-09"
Description: Network

Parameters:
  Prefix:
    Description: Enter Prefix.
    Type: String
    Default: sample

Resources:
#---------------------------------------------------#
# VPC
#---------------------------------------------------#
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      InstanceTenancy: default
      Tags:
        - Key: Name
          Value: !Sub ${Prefix}-vpc

#---------------------------------------------------#
# RouteTable
#---------------------------------------------------#
  PrivateRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: Name
          Value: !Sub ${Prefix}-private-rt

#---------------------------------------------------#
# Subnet1A
#---------------------------------------------------#
  PrivateSubnet1A:
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: 10.0.16.0/20
      AvailabilityZone: !Select
        - 0
        - Fn::GetAZs: !Ref AWS::Region
      Tags:
        - Key: Name
          Value: !Sub ${Prefix}-private-subnet-1a

3. インポート実行

インポートは次の3ステップで実行していきます。

  1. 変更セットの作成 (CLIコマンド：create-change-set)
  2. 変更セットの確認 (CLIコマンド：describe-change-set)
  3. 変更セットの実行 (CLIコマンド：execute-change-set)

Import.jsonとImport-Network.yamlをCloudShellにアップロードし、コマンドを実行します。

# 1. 変更セットの作成
aws cloudformation create-change-set \
    --stack-name sample-network-stack --change-set-name sample-network-change-set \
    --change-set-type IMPORT \
    --resources-to-import file://Import.json \
    --template-body file://Import-Network.yaml

# 2. 変更セットの確認
aws cloudformation describe-change-set \
    --stack-name sample-network-stack \
    --change-set-name sample-network-change-set

# 3. 変更セットの実行
aws cloudformation execute-change-set \
    --stack-name sample-network-stack \
    --change-set-name sample-network-change-set

サブネットが再びスタック管理下となったことを確認します。

# ネットワークスタックの管理下にあるリソースを確認
aws cloudformation describe-stack-resources \
    --stack-name sample-network-stack \
    --query "join(', ', StackResources[*].LogicalResourceId)" --output text \
    --output text

無事に成功しました。

4. 削除してしまったその他のリソースを再作成する

ここまでくればあと一息です。

最初のスタックではVPCエンドポイントなども管理していましたが、Destructive-Network.yamlで上書きした際にこれらのリソースは削除されてしまいました。

ですので、最後の手順として元のNetwork.yamlでデプロイして元の状態に戻しましょう。

# 1. ネットワークスタックを作成
aws cloudformation deploy \
    --template-file Network.yaml \
    --stack-name  sample-network-stack

# 2. ネットワークスタックの管理下にあるリソースを確認
aws cloudformation describe-stack-resources \
    --stack-name sample-network-stack \
    --query "join(', ', StackResources[*].LogicalResourceId)" --output text \
    --output text

5. 復旧を確認

最後にLambda関数を実行して、ネットワークの疎通に問題がないことを確認して終わりとします。

# 1. Lambda関数を実行
aws lambda invoke \
    --function-name sample-function \
    outputfile.txt

# 2. S3バケット内のオブジェクト数を確認
#    → 「Total Objects: 2」と表示される
aws s3 ls s3://sample-check-network-status-bucket\
    --recursive \
    --summarize

おまけ + 参考文献

おまけ

VPC Lambdaを含むスタックを削除しようとすると、ENIが引っかかって削除に時間がかかることがあります。(私の環境では25分ほどかかりました。)

そんなときのTipsとして、先にCLI操作によってLambdaの設定からVPC設定を外してしまいましょう。

# 1. S3バケットを空にする
aws s3 rm s3://sample-check-network-status-bucket --recursive

# 2. Lambda関数からVPC設定を外す
aws lambda update-function-configuration \
    --function-name sample-function \
    --vpc-config SubnetIds=[],SecurityGroupIds=[]

# 3. Lambdaスタックを削除
aws cloudformation delete-stack \
    --stack-name sample-lambda-stack

# 4. ネットワークスタックを削除(※依存関係があるため、Lambdaスタックが削除されたことを確認してから実行)
aws cloudformation delete-stack \
    --stack-name sample-network-stack

以上です。

参考文献

]]> https://tech-itoya.com/cloudformation%e3%82%b9%e3%82%bf%e3%83%83%e3%82%af%e3%81%8b%e3%82%89%e5%a4%96%e3%82%8c%e3%81%9f%e3%82%b5%e3%83%96%e3%83%8d%e3%83%83%e3%83%88%e3%82%92%e3%82%b9%e3%82%bf%e3%83%83%e3%82%af%e7%ae%a1/feed/ 0 Amazon QuickSightとMicrosoft Entra IDをSAML連携させた場合のSessionDurationの有効範囲について https://tech-itoya.com/amazon-quicksight%e3%81%a8microsoft-entra-id%e3%82%92saml%e9%80%a3%e6%90%ba%e3%81%95%e3%81%9b%e3%81%9f%e5%a0%b4%e5%90%88%e3%81%aesessionduration%e3%81%ae%e5%bd%b9%e5%89%b2/ https://tech-itoya.com/amazon-quicksight%e3%81%a8microsoft-entra-id%e3%82%92saml%e9%80%a3%e6%90%ba%e3%81%95%e3%81%9b%e3%81%9f%e5%a0%b4%e5%90%88%e3%81%aesessionduration%e3%81%ae%e5%bd%b9%e5%89%b2/#respond Wed, 18 Sep 2024 16:07:25 +0000 https://tech-itoya.com/?p=30 こんにちは。Dantoです。

今回は、Amazon QuickSightとMicrosoft Entra IDをSAML連携した場合のSessionDuration値の役割について書いていきます。

TL; DR;

  • SessionDurationの設定値はQuickSightのセッション継続時間とは無関係
    • QuickSightのセッション継続時間は独自管理となっており、12時間固定

本題

前提

Amazon QuickSightとMicrosoft Entra IDをSAML連携させた場合、オプションでEntra ID側にSessionDuration値を設定することができます。

SessionDurationとは、読んで字のごとく「セッションを継続させる時間」を表す属性ですが、念のため公式ドキュメントの記述を引用しておきます。

(Optional) You can use an Attribute element with the Name attribute set to https://aws.amazon.com/SAML/Attributes/SessionDuration". This element contains one AttributeValue element that specifies how long the user can access the AWS Management Console before having to request new temporary credentials. The value is an integer representing the number of seconds for the session. The value can range from 900 seconds (15 minutes) to 43200 seconds (12 hours). If this attribute is not present, then the credential last for one hour (the default value of the DurationSeconds parameter of the AssumeRoleWithSAML API).

(オプション) Name 属性を https://aws.amazon.com/SAML/Attributes/SessionDuration” に設定した Attribute 要素を使用できます。この要素には AttributeValue 要素が 1 つ含まれ、ユーザーが新しい一時的な認証情報を要求するまでに AWS Management Console にアクセスできる時間を指定します。値は、セッションの秒数を表す整数です。値の範囲は 900 秒（15 分）から 43200 秒（12 時間）です。この属性が存在しない場合は、クレデンシャルは 1 時間持続します (AssumeRoleWithSAML API の DurationSeconds パラメータのデフォルト値)。

ドキュメントからは３つの情報を読み取ることができそうです。

  • https://aws.amazon.com/SAML/Attributes/SessionDurationの値として整数値を設定できる
  • SessionDurationではAWSマネージメントコンソールにアクセスできる時間を指定する
  • 設定値の範囲は900(15分)から43200(12時間)
    • デフォルトは3600(1時間)

ひとまず、SessionDurationに設定した値はAWSマネージメントコンソールにアクセス可能な時間と関係していることは理解しました。

また、ここではIDプロバイダにIAMロールを割り当てる際に、許可されるアクセスとして「プログラムと AWS マネジメントコンソールへのアクセスを許可する」を選択しています。

疑問

SessionDurationの値は、QuickSightコンソールにアクセスできるセッションの継続時間とは関係ないのか…？

(SessionDurationを900秒に設定したらQuickSightのセッション継続時間も900秒になるのか…？)

(↓↓↓QuickSightコンソール)

結論

SessionDurationの設定値とQuickSight側のセッション継続時間は無関係

あくまで、SessionDurationはAWSマネージメントコンソールにアクセス可能なセッションとのみ関係しているそうです。

また、QuickSight側のセッション継続時間は独自管理であり、12時間固定で変更はできません。

なので、SessionDurationを設定値を900とした場合のセッション継続時間は

  • AWSマネージメントコンソール : 15分
  • QuickSightコンソール : 12時間

となります。

おまけ

厄介なことに、IDフェデレーションによってQuickSightにサインインするユーザは、AWSコンソールにもサインインできてしまいます。

※AWSマネージメントコンソールへのサインインを防ぐ方法はありません。

ただし、引き受けさせるIAMロールの権限を絞っておけば、基本的には何もできない状態にはできます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "quicksight",
            "Effect": "Allow",
            "Action": [
                "quicksight:DescribeDashboard",
                "quicksight:ListDashboards"
            ],
            "Resource": "arn:aws:quicksight::123456789012:*"
        }
    ]
}

AWSマネージメントコンソールへのアクセスを許容し難い場合は、せめてもの対策として

  • IDプロバイダに割り当てるIAMロールの権限を最小限にする
  • SessionDurationの値を最小限にする

この辺は講じてもよいかもしれません。

以上です。

参考記事

]]> https://tech-itoya.com/amazon-quicksight%e3%81%a8microsoft-entra-id%e3%82%92saml%e9%80%a3%e6%90%ba%e3%81%95%e3%81%9b%e3%81%9f%e5%a0%b4%e5%90%88%e3%81%aesessionduration%e3%81%ae%e5%bd%b9%e5%89%b2/feed/ 0