Amazon Web Services ブログ

Category: AWS Identity and Access Management (IAM)

SaaSテナント分離をAWS IAMとABACで実装する方法

この記事は、How to implement SaaS tenant isolation with ABAC and AWS IAMを訳したものです。 マルチテナントアプリケーションにおいては各テナントのリソースが他のテナントからアクセスできないように設計を行う必要があります。AWS Identity and Access Management (IAM) は多くの場合、この目的を達成するための重要な要素となりえます。一方で、IAMを用いることによる課題の一つとして、テナント分離を実現するのに必要な IAM ポリシーの数と複雑さが急速に拡大することにより分離モデルの規模と管理性に影響を与えることが挙げられます。IAM の 属性ベースのアクセスコントロール (ABAC) の仕組みはこの課題を解決するための方法を開発者に提供しています。 このブログ記事では、IAM の ABAC を用いてマルチテナント環境のテナント分離を実装する方法について解説します。

Read More

IAM Access Analyzer の更新 – ポリシー検証

AWS Identity and Access Management (IAM) は AWS の重要で基本的な部分です。特定の AWS のサービスやリソースへのアクセスのレベルを定義する IAM ポリシーおよびサービスコントロールポリシー (SCP) を作成して、そうしたポリシーを IAM プリンシパル (ユーザーおよびロール)、ユーザーの グループ、または AWS リソースにアタッチすることができます。IAM で得られるきめ細かなコントロールでは、IAM を適切に使用する責任が発生します。ほとんどの場合、最小権限アクセス確立するのが妥当です。IAM チュートリアルは詳細を学ぶのに役立ち、IAM Access Analyzer は、外部エンティティと共有されているリソースを特定するのに役立ちます。最近、IAM Access Analyzer の更新を開始しました。これにより、アクセス許可の変更をデプロイする前に S3 バケットへのアクセスを検証することができます。 新しいポリシーの検証 本日、IAM Access Analyzer にポリシー検証を追加することを発表いたします。この強力な新機能は、時間をかけてテストされた AWS のベストプラクティスを活用する IAM ポリシーと SCP を構築するのに役立ちます。 デベロッパーおよびセキュリティチームが使用できるように設計されており、IAM プリンシパルにポリシーがアタッチされる前に検証が行われます。セキュリティ体制を改善し、大規模なポリシー管理を簡素化できるように設計された 100 以上のチェックが実行されます。各チェックの結果には、詳細な情報や具体的な推奨事項が含まれます。 検証には、IAM コンソールの JSON ポリシーエディタ、ならびにコマンドライン (AWS Access Analyzer 検証ポリシー) […]

Read More

SAMLセッションタグを使用してフェデレーションユーザーのSession Managerアクセスを構成する

このブログ投稿では、フェデレーションユーザーに対して、AWS Systems Manager Session Managerへのアクセス権限を属性ベースのアクセスコントロール(ABAC=Attribute Based Access Control)にて設定する方法を示します。SAMLセッションタグを使用することで、外部IDシステムで定義された属性をAWS内のABACの判定の一部として使用できます。たとえば、AWS Identity and Access Management(IAM)ユーザーが所属する部門に基づいて、特定のマネージドインスタンスへのアクセスを許可することができます。フェデレーションユーザーが使用できる属性の詳細については、「新しい ID フェデレーション – AWS でアクセスコントロールに従業員属性を使用する」を参照してください。

Read More

サーバーレス LAMP スタック – Part 2: リレーショナルデータベース

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1:サーバーレス LAMP スタックの紹介 パート3:Webサーバーの置き換え パート4:サーバーレス Laravel アプリの構築 パート5:CDK コンストラクトライブラリ パート6:MVC からサーバーレスマイクロサービスへ この投稿では、サーバーレスアプリケーションで Amazon Aurora MySQLリレーショナルデータベースを使用する方法を学びます。Amazon RDS Proxy を使用してデータベースへの接続をプールおよび共有する方法と、構成を選択する方法を示します。この投稿のコード例は PHP で記述されており、この GitHubリポジトリにあります。なお、この概念自体は、AWS Lambda でサポートされている他のランタイム言語にも適用できますので、PHP に限定しない内容としてお読みいただけます。 サーバーレス LAMP スタック このサーバーレス LAMP スタックアーキテクチャについては、この記事で説明しています。このアーキテクチャでは、PHP Lambda 関数を使用して、Amazon Aurora MySQL データベースの読み取りと書き込みを行います。 Amazon Aurora は、MySQL および PostgreSQL データベースに高いパフォーマンスと可用性を提供します。基盤となるストレージは、最大64 テビバイト(TiB)まで需要に応じて自動的に拡張されます。 Amazon Aurora DB […]

Read More

VPC設定にAWS Lambda IAM条件キーを使用する

本投稿は、Senior Developer Advocate, Julian Woodの寄稿によるものです。 AWS Identity and Access Management(IAM)条件キーを使用して、AWS Lambda 関数のAmazon Virtual Private Cloud(VPC)設定を制御できるようになりました 。 IAM条件キーを使用すると、IAMポリシーステートメントが適用される条件をさらに絞り込むことができます。関数を作成および更新する権限を付与するときに、IAMポリシーで新しい条件キーを使用できます。 VPC設定の3つの新しい条件キーは、lambda:VpcIds、lambda:SubnetIds、そして、 lambda:SecurityGroupIds です。キーにより、ユーザーが1つ以上の許可されたVPC、サブネット、およびセキュリティグループに接続された関数のみをデプロイできるようにすることができます。ユーザーが許可されていないVPC設定で関数を作成または更新しようとすると、Lambdaは操作を拒否します。 LambdaとVPCの関係を理解する Lambdaの実行環境はすべて、Lambdaサービスが所有するVPC内で動作します。 Lambda関数は、Lambda API を呼び出すことによってのみ呼び出すことができます。関数が実行される実行環境への直接のネットワークアクセスはありません。 非VPC接続のLambda関数 Lambda関数がカスタマーアカウントのVPCに接続するように構成されていない場合、関数はパブリックインターネットで利用可能なすべてのリソースにアクセスできます。これには、他のAWSサービス、APIのHTTPSエンドポイント、またはAWS外のサービスとエンドポイントが含まれます。関数はVPC内のプライベートリソースに直接には接続できません。 VPC接続のLambda関数 Lambda関数を設定して、カスタマーアカウントのVPC内のプライベートサブネットに接続できます。 Lambda関数がカスタマーアカウントVPCに接続するように設定されている場合も、そのLambda関数は引き続きAWS LambdaサービスVPC内で実行されます。この場合、Lambda関数はすべてのネットワークトラフィックをカスタマーアカウント内VPC経由で送信し、このカスタマーVPCのネットワーク制御に従います。これらのコントロールを使用して、セキュリティグループ とネットワークACL を設定し関数が接続可能な範囲を制御できます。Lambda関数からの送信トラフィックは独自のネットワークアドレス空間から送信され、VPCフローログ を使用してネットワークを可視化できます。 パブリックインターネットを含むネットワークロケーションへのアクセスを制限できます。 カスタマーアカウント内のVPCに接続されたLambda関数は、デフォルトではインターネットにアクセスできません。関数にインターネットへのアクセスを許可するには、送信トラフィックをパブリックサブネットのネットワークアドレス変換(NAT)ゲートウェイ にルーティングできます。 Lambda関数を設定してカスタマーアカウント内のVPCに接続すると、AWS Hyperplane によって管理される共有Elastic Network Interface(ENI)が使用されます。この接続により、VPC-to-VPC NATが作成され、クロスアカウントに接続されます。これにより、Lambda関数からプライベートリソースへのネットワークアクセスが可能になります。 AWS Lambda サービスVPCからVPC-to-VPT NATを利用しカスタマーVPCへ Hyperplane ENIは、Lambdaサービスが制御し、カスタマーアカウント内のVPCに存在するマネージドネットワークインターフェースリソースです。複数の実行環境がENIを共有して、カスタマーアカウントのVPC内のリソースに安全にアクセスします。カスタマー側からのLambda実行環境(LambdaサービスVPC内)への直接のネットワークアクセスは出来ないことにご注意ください。 ENIはいつ作られるのか? Lambda関数が作成されるか、そのVPC設定が更新されると、ネットワークインターフェイスの作成が行われます。関数が呼び出されると、実行環境は事前に作成されたネットワークインターフェースを使用し、そのインターフェースへのネットワークトンネルをすばやく確立します。これにより、コールドスタート時のネットワークインターフェースの作成と接続に関連していたレイテンシが削減 されています。 どのくらいの数のENIが必要か? ネットワークインターフェイスは実行環境全体で共有されるため、通常、関数ごとに必要なネットワークインターフェイスはほんの一握りです。アカウント内の関数全体で一意のセキュリティグループとサブネットのペアごとに、個別のネットワークインターフェイスが必要です。同じアカウントの複数の関数が同じセキュリティグループとサブネットのペアを使用する場合、同じネットワークインターフェイスを再利用します。このように、複数の関数を備えているが、ネットワークとセキュリティの構成が同じである単一のアプリケーションは、既存のインターフェース構成の恩恵を受けることができます。 関数のスケーリングは、ネットワークインターフェイスの数に直接関係しなくなりました。Hyperplane […]

Read More

AWS アカウントのセキュリティを改善するための 10 個の項目

クラウド・セキュリティを向上させたいと考えているなら、AWS のチーフ・インフォメーション・セキュリティ・オフィサー (CISO) であるステファン・シュミットが AWS re:Invent 2019で発表したクラウド・セキュリティのための上位 10 個の項目 を参照してみてはいかがでしょうか? 下記が項目のサマリーです。皆様の理解のために、順番に説明していきます。 1) アカウント情報を正しく保つ AWS が AWS アカウントについて連絡が必要な場合、AWS マネジメントコンソールで設定された連絡先の情報を利用します。これは、アカウントを作成する時に指定した E メールアドレス、代替の連絡先の中で指定されている E メールアドレスになります。全ての E メールアドレスは個人に依存しないようにエイリアスのアドレスにするべきです。また、定期的に指定している E メールアドレスが有効で、E メールが届いた時に返信可能かどうかを確認するプロセスが必要です。特に、 abuse@amazon.com から受信する可能性のあるセキュリティに関する通知に返信出来るかどうかが重要です。あなた自身が不在の時に、他の誰かがメール受信を出来るように代替の連絡先指定のマニュアルページで確認してみてください。 2) 多要素認証 (MFA) を利用する MFA は不正なアクセスからアカウントを保護するためのベストな方法の1つです。MFA をルートユーザおよび AWS Identity and Access Management (IAM) ユーザに対して設定してください。AWS へのアクセス制御に AWS Single Sign-On (SSO) を使っていたり、企業内の ID ストアとフェデレーションを指定している場合には、MFA を Identity Provider (IdP) […]

Read More

AWS Identity and Access Management (IAM) Access Analyzer を使った意図しないリソースアクセスの特定

本日の発表をここでシェアしたいと思います。この発表は、AWS 上のビルダーの方のためのセキュリティ強化のみに留まりません。また、設定なしに利用料金不要でオンにすることが出来ます。AWS は、AWS Identity and Access Management (IAM) Access Analyzer と呼ばれる今までにない機能をリリースします。 IAM Acess Analyzer は数学的なアルゴリズムを使って AWS 上のリソースにアタッチされている アクセス制御ポリシーを分析し、他のアカウントもしくは、誰もがアクセスできるリソースが無いか見つけ出します。IAM Access Analyzer は継続的にAmazon Simple Storage Service (S3) バケット、IAM ロール、 AWS Key Management Service (KMS) キー、AWS Lambda 関数、 Amazon Simple Queue Service (SQS) キューといったリソースのポリシーを監視します。 IAM Access Analyzer によって、アクセス制御状況のインパクトを集約、可視化し、 利用されているアカウントの外側からの意図しないアクセスからリソースが保護されていることを確認出来ます。 いくつかの例をご紹介します。 IAM Access Analyzer の結果は my-bucket-1 という S3 バケットが ID 123456789012 の AWS […]

Read More

サンドボックス、開発、テスト環境で IAM ポリシー作成を一元化および自動化する方法

本番環境に対応したアーキテクチャに移行する際、お客様のアプリケーションチームはサンドボックス環境で AWS のサービスを試して、AWS の進化していくイノベーションに対応することができます。アプリケーションチームは、さまざまな AWS のサービスとリソースにタイムリーにアクセスする必要があります。つまり、最低限の権限を与えられることを保証するメカニズムを必要とします。通常、アプリケーションチームは、定期的に Amazon Elastic Block Store のスナップショットバックアップを行う AWS Lambda 関数や、セキュリティチームが管理する一元化された情報セキュリティアカウントにイベントを送信する Amazon CloudWatch Events ルールなどの管理リソースにアクセスできません。 このブログ投稿では、さまざまなサンドボックス、開発、テスト環境で作業しているアプリケーションチームが AWS Identity and Access Management (IAM) ポリシーを作成および検証するため、一元化かつ自動化したワークフローを作成する方法をご紹介します。セキュリティ開発者は、セキュリティチームの特定の要件に従ってこのワークフローをカスタマイズできます。セキュリティ開発者は、アカウントの種類または所有チームに基づいたアクセス許可セットを制限するロジックも作成できます。AWS CodePipeline を使用して、さまざまな段階や複数の AWS アカウントにわたるワークフローを作成および管理します。これについては、次のセクションで詳しく説明します。 ソリューションの概要 次のシナリオから始めましょう。Alice は AWS サンドボックスアカウントの管理者です。これは、組織のデータサイエンティストが Amazon Athena や Amazon EMR などの AWS の分析サービスを試す際に使用します。データサイエンティストは、機密情報が取り出された後、実際のデータセットの一部に対して分析ジョブのサンプルを実行することで、これらのサービスが本番ユースケースに適合しているかを評価します。データセットは既存の Amazon Simple Storage Service (Amazon S3) バケットに保存されます。Alice は新しいプロジェクトごとに、プロジェクトチームに要求された Amazon S3 バケットにアクセスして、分析クラスターを作成できるようにする新しい IAM […]

Read More

Kubernetes サービスアカウントに対するきめ細やかな IAM ロール割り当ての紹介

本投稿は Micah Hausler と Michael Hausenblas による記事を翻訳したものです AWS ではお客様のニーズに最優先にフォーカスしています。Amazon EKS におけるアクセス権制御に関して、みなさまは「パブリックコンテナロードマップ」の Issue #23 にて EKS でのきめ細かい IAM ロールの利用方法 を求められていました。このニーズに応えるため、コミュニティでは kube2iam、kiam や Zalando’s IAM controller といったいくつかのオープンソースソリューションが登場しました。これらのソリューションは素晴らしいプロダクトであるだけでなく、それぞれのアプローチの要件及び制約は何なのかについて多くの方の理解を促すことを可能にしました。 そして今、柔軟かつ簡単に利用可能なソリューションがやってきました。私たちの重要なゴールとして、粒度の高いロールを Node レベルではなくPod レベルでの提供がありました。私たちが今回考え出したソリューションもオープンソースとして公開されているため、eksctl での Amazon EKS クラスター作成時にも利用できますし、DIY アプローチでの Kubernetes クラスターとしてポピュラーな kops によって作成されたようなクラスタにおいてもご利用いただくことが可能です。 アクセスコントロール: IAM と RBAC Kubernetes on AWS では、補完しあう2つのアクセスコントロール手法が動作します。AWS Identity and Access Management (IAM) は AWS サービスへのアクセス許可、例えばあるアプリケーションが S3 […]

Read More

プログラムからのアクセス利用時に AWS アカウントを保護するためのガイドライン

AWS を利用する際に最も重要なこととして、AWS リソースのセキュリティの確保があります。誰にリソースにアクセスさせるのか、注意深くコントロールする必要があります。これは、AWS ユーザーがプログラムを使ったアクセスをしている場合にも同様です。プログラムからのアクセスは、自社で作成したアプリケーションもしくはサードパーティーのツールから AWS リソースにアクションすることを実現します。AWS サービス側でアクセスリクエストを認可させるためにアクセスキー ID とシークレットアクセスキーを使ってリクエストに署名することが可能です。このようにプログラムによるアクセスは非常にパワフルなため、アクセスキー ID とシークレットアクセスキーを保護するためにベスト・プラクティスを活用することが重要です。これは不意のアクセスあるいは悪意のあるアクテビティビティからアカウントを保護するために重要です。この投稿では、いくつかの基本的なガイドラインを提示し、アカウントを保護する方法を示します。また、プログラムからの AWS リソースへのアクセスを行う際に利用出来るいくつかの方法を提示します。 ルートアカウントを保護する AWS のルートアカウント –  AWS にサインナップするときに最初に作られるアカウント – は全ての AWS のリソースに無制限でアクセス出来ます。ルートアカウントには権限による制御が効きません。したがって、AWS はルートアカウントに対してアクセスキーを作成しないように常におすすめしています。アクセスキーを与えると利用者がアカウント全体を廃止するような強力な権限を得てしまいます。ルートアカウントにアクセスキーを作成するかわりに、利用者は個別の AWS Identity and Access Management(IAM)ユーザーを作成して利用することができます。さらに、最小権限の考え方に従い、それぞれの IAM ユーザーに対してタスクを実行するのに必要な権限のみを許可します。複数の IAM ユーザーの権限を簡単に管理するために、同じ権限を持つユーザーを IAM グループにまとめる方法も使えます。 ルートアカウントは常に多要素認証(MFA)で保護するべきです。このセキュリティに関する追加の保護は許可されていないログインからアカウントを保護することに役立ちます。多要素認証とは、認証に複数の要素を使うことで、パスワードのような知識認証要素と、MFA デバイスのような所有物認証要素を同時に使うことです。 AWS はバーチャルとハードウェアの 両方のMFA 用のデバイス、さらに U2F セキュリティキーを多要素認証用としてサポートしています。 AWS アカウントに対するアクセスを許可するときの考え方 ユーザーに AWS マネジメントコンソールやコマンドラインインターフェース(CLI)にアクセスを許可するには2つの選択肢があります。1つ目は、IAM サービスによって管理されるユーザー名とパスワードでログインする ID を作ることです。もう1つは、IDフェデレーションを利用して、既に企業の中に存在する認証情報を使って AWS コンソールや CLI にログインさせることです。それぞれのアプローチには異なるユースケースがあります。フェデレーションは、既に集中管理されたディレクトリがあるか、現在の制約である5000人以上の IAM […]

Read More