Amazon Web Services ブログ

Tag: AWS IAM

DeNA TechCon 2018 – AWS IoTを用いたDeNAオートモーティブアーキテクチャ

AWS IoTを用いたDeNAオートモーティブアーキテクチャ   先日、2018年2月7日に、渋谷ヒカリエにて開催された、DeNA TechCon 2018におきまして、「AWS IoTを用いたDeNAオートモーティブアーキテクチャ」と題した、DeNAの放地宏佳様による講演がありました。 AWS IoTをふんだんに活用して、Vehicle Architecture on AWSを実現されている舞台裏に関し、車両情報管理基盤の話を中心に、詳細な内容を発表いただきました。 車載デバイスから車両管理情報を収集して、車両情報集約基盤へと連携している具体的なワークフロー デバイス認証にどのような実装を施して、AWS IAMとのスムーズな連携を行なっているのかの詳細な解説 ビジネス要求の変化に柔軟に対応できるよう、拡張性を考慮したデバイスシャドウとルールエンジンの組み合わせによる利用の工夫 バックエンドのElasticsearchへのindexingのしやすさを考慮したデバイスシャドウのアトリビュート設計に対する工夫 もちろん、この他にも様々なAWSを活用いただいた事例を、Deep Learningや機械学習など、多くのセッションで触れていただいております。 ぜひ皆様にも、DeNA TechCon 2018のイベントページに訪れて、それぞれのセッションスライドに目を通していただきたいです。 DeNA様、放地様、素晴らしいカンファレンスと発表を、本当にありがとうございました!   ソリューションアーキテクト 半場光晴

Read More

マネージメントコンソールからも、既存のEC2インスタンスにIAMロールを簡単にアタッチ、変更できるようになりました

AWS Identity and Access Management(IAM)ロールを利用すると、Amazon EC2上で動作するアプリケーションは一時的なセキュリティ資格を使用することにより安全に稼働することができます。また、アプリケーションが使用するAWSセキュリティ資格情報を利用者が管理する必要がないため、アプリケーションがインスタンスから安全にAPIリクエストが発行できます。先日、AWS CLI, AWS SDKを使用し、既存のEC2インスタンスにIAMロールを付加することで、アプリケーションに一時的なセキュリティ資格情報を使用できるようになりました。詳細は、「既存のAmazon EC2インスタンスにIAM Roleがアタッチできるようになりました」を確認下さい。 そして今日から、EC2コンソール(マネージメント コンソール)からも、既存のEC2インスタンスにIAMロールをアタッチできるようになりました。 EC2コンソールを使用して、既存のインスタンスにアタッチされたIAMロールを置き換えることもできます。 このブログ記事では、EC2コンソールから既存のEC2インスタンスにIAMロールを割り当てる方法を示します。 EC2コンソールから、既存のEC2インスタンスにIAMロールをアタッチする EC2コンソールから既存のEC2インスタンスにIAMロールを添付するには: 1. EC2コンソールに移動します 2. ナビゲーションペインでInstancesを選択します。  3. IAMロールをアタッチするインスタンスを選択します。 IAMロールがまだアタッチされていないことを確認するには、インスタンスの[Description]タブのIAMロールの値が空であることを確認します。 4. [Actions]を選択し、[Instance Settings]を選択して、ドロップダウンリストから[IAMロールのアタッチ/置換]を選択します。 5. [Attach / Replace IAM role]ページから、添付するロール(この例ではEC2Role1を選択します)をドロップダウンリストから選択します。 注意:”Create new IAM role (新しいIAMロールの作成)”を選択することで、新しいロールを作成することもできます。 詳細については、「IAMコンソールを使用してIAMロールを作成するには」を参照してください。 6. IAMロールを選択したら、「Apply」を選択して次のステップに進みます。 私の場合、次のスクリーンショットに示すように、IAMの役割はEC2インスタンスに正常にアタッチされました。 ロールが目的のEC2インスタンスに関連付けられていることを確認するには、インスタンスの詳細ページに移動します。次のスクリーンショットのようにEC2Role1がIAMロールであることが確認できます。 この投稿に関するコメントがある方は、下記の「コメント」セクションに投稿頂きますと助かります。 ご質問やご提案がありましたら、IAMフォーラムの新しいスレッドからお問い合わせください。 – Mari 翻訳はPartner SA 酒徳が担当しました。原文はこちらです。

Read More

EMRFSを利用して、別AWSアカウントからデータを安全に分析する

分析されるデータは、異なるアカウントが所有するバケットに分散されることがあります。データのセキュリティを確保するためには、適切な認証情報管理が必要です。これは、さまざまな部門の異なるAmazon S3バケットにデータを格納している大企業にとって特に当てはまります。例えば、顧客サービス部門は、研究部門が所有するデータにアクセスする必要があるかもしれませんが、研究部門はそのアクセスを安全な方法で提供する必要があります。 データを保護するこの側面は非常に複雑になる可能性があります。 Amazon EMRは、統合メカニズムを使用して、S3に格納されたデータにアクセスするためのユーザー認証情報を提供します。 EMR上でアプリケーション(Hive、Sparkなど)を使用してS3バケットとの間でファイルを読み書きする場合、S3 API呼び出しには認証するための適切な認証情報で署名する必要があります。 通常、これらの認証情報は、クラスターの起動時に指定するEC2インスタンスプロファイルによって提供されます。そのオブジェクトが異なる認証情報セットを必要とするため、EC2インスタンスプロファイルの認証情報がS3オブジェクトにアクセスするのに十分でない場合はどうなるでしょうか? このポストは、カスタム認証プロバイダを使用して、EMRFSのデフォルトの認証プロバイダがアクセスできないS3オブジェクトにアクセスする方法を示しています。

Read More

サーバレス JavaScript アプリケーションで SAML: Part I

このブログ記事は AWS の Richard Threlkeld, Gene Ting, Stefano Buliani によって AWS Compute Blog に投稿された「SAML for Your Serverless JavaScript Application: Part I」の翻訳記事です。 このブログ記事に掲載したコードや SAM テンプレートの全体は samljs-serverless-sample GitHub レポジトリにあります。手動でリソースを作成する事もできますが、GitHub レポジトリにある SAM テンプレートを使ってリソースを作成することを強くお勧めします。 SAML 認証連携を実現したくありませんか? AWS プラットフォームで使うことができる一時的なセキュリティ認証情報の発行を、短期間の SAML アサーションを交換で実現できます。 エンタープライズ Web アプリケーションを構築する時は、認証や認可が一貫して行われ業界のベストプラクティスに沿っている事が必須事項です。AWS では、ユーザに一意のIDを作成し、AWS のサービスにアクセスできる短期間の認証情報を使えるようにできる Amazon Cognito と呼ぶサービスを構築しました。これらの認証情報は、IAM ポリシーに基づくロールと関連付けて、異なるリソースへのアクセスを許可や拒否する事ができます。 この記事では、Amazon Cognito で SAML プロバイダと認証連携を行う異なる方式を紹介していきます。応用すると、異なるタイプの認証プロバイダ (IdP) と連携させることができます。Facebook、Twitterやその他のサードパーティのソーシャルメディアを IdP にする事もできます。Amazon Cognito […]

Read More

AWSでの疎結合データセットの適合、検索、分析

あなたは刺激的な仮説を思いつきました。そして今、あなたは、それを証明する(あるいは反論する)ためにできるだけ多くのデータを見つけて分析したいと思っています。適用可能な多くのデータセットがありますが、それらは異なる人によって異なる時間に作成され、共通の標準形式に準拠していません。異なるものを意味する変数に対して同じ名前を、同じものを意味する変数に対して異なる名前を使用しています。異なる測定単位と異なるカテゴリを使用しています。あるものは他のものより多くの変数を持っています。そして、それらはすべてデータ品質の問題を抱えています(例えば、日時が間違っている、地理座標が間違っているなど)。 最初に、これらのデータセットを適合させ、同じことを意味する変数を識別し、これらの変数が同じ名前と単位を持つことを確認する方法が必要です。無効なデータでレコードをクリーンアップまたは削除する必要もあります。 データセットが適合したら、データを検索して、興味のあるデータセットを見つける必要があります。それらのすべてにあなたの仮説に関連するレコードがあるわけではありませんので、いくつかの重要な変数に絞り込んでデータセットを絞り込み、十分に一致するレコードが含まれていることを確認する必要があります。 関心のあるデータセットを特定したら、そのデータにカスタム分析を実行して仮説を証明し、美しいビジュアライゼーションを作成して世界と共有することができます。 このブログ記事では、これらの問題を解決する方法を示すサンプルアプリケーションについて説明します。サンプルアプリケーションをインストールすると、次のようになります。 異なる3つのデータセットを適合させて索引付けし、検索可能にします。 事前分析を行い、関連するデータセットを見つけるために、データセットを検索するための、データ駆動のカスタマイズ可能なUIを提示します。 Amazon AthenaやAmazon QuickSightとの統合により、カスタム解析やビジュアライゼーションが可能です

Read More

既存のAmazon EC2インスタンスにIAM Roleがアタッチできるようになりました

AWS Identity and Access Management(IAM) のロール を利用することで、Amazon EC2上で実行するアプリケーションは、AWSが自動的に作成、配布、およびローテーションする一時的なセキュリティ資格情報を利用することができます。一時的な資格情報を使用することは、IAMのベストプラクティスとなっており、インスタンスで長期間の鍵の管理する必要がなくなります。IAM Roles for EC2 (EC2のIAMロール)を使用することで、長期的なAWSアクセスキーを手動またはプログラムで管理する必要もなくなります。そして本日、既存のEC2インスタンスにIAMロールをアタッチすることが可能になり、アプリケーションはAWSによって提供される一時的なセキュリティ資格情報を使用できるようにするよう設定できるようになりました。 また、既存のEC2インスタンスに添付されているIAMロールを変更することも可能になります。 このブログ記事では、AWS CLIを使用して既存のEC2インスタンスにIAMロールをアタッチする方法をご紹介します。 ソリューションの概要 このブログ記事のソリューションでは、 1. IAMロールの作成 2. IAMロールなしで起動された既存のEC2インスタンスにIAMロールをアタッチ 3. アタッチされているIAMロールの付け替え この記事では、新しく作成されたIAMロールを”YourNewRole“とします。このロールに関連付けられたインスタンス・プロファイルを”YourNewRole-Instance-Profile“、 既存のインスタンスを”YourInstanceId“とすることにます。 これら(赤字)はアカウントのリソース名に置き換えてください。 ここでは、AWSコマンドラインインターフェイス(CLI)の設定が完了しており、IAMロールを作成する権限、EC2 APIを呼び出す権限を持っていることを前提としています。 IAMロールの作成 注:既存のIAMロールをアタッチする場合は、このポストの「IAMロールなしで最初に起動された既存のEC2インスタンスにIAMロールをアタッチ」に進んでください。 またAWSマネージメントコンソールを使用してIAMロールを作成してから、同じセクションに進むこともできます。 AWS CLIからIAMロールを作成する前に、信頼ポリシーを作成する必要があります。 信頼ポリシーは、EC2などのAWSサービスがアプリケーションに代わってIAMロールを引き受けることを許可します。 信頼ポリシーを作成するには、下記のポリシーをコピーし、YourNewRole-Trust-Policy.jsonという名前で保存したテキストファイルに貼り付けます。 { “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Allow”, “Principal”: { “Service”: “ec2.amazonaws.com” }, “Action”: “sts:AssumeRole” } ] } 信頼ポリシーを作成すると、既存のEC2インスタンスにアタッチできるIAMロールを作成する準備が整いました。 AWS CLIからIAMロールを作成 1. AWS […]

Read More

ECSタスクのためのIAMロールによってコンテナ利用アプリケーションをより安全にする

Amazon ECSでは、コンテナから簡単にAPIリクエストを行うために、Amazon EC2のIAMロールをいつでも使うことができます。これによって、AWSの認証情報をコードや設定ファイルに保存しないというAWSのベストプラクティスに従うことができる上に。鍵の自動ローテーションといった利点も得られます。 例えば、ECSとAmazon S3を使った秘匿情報管理システムを作ったり、Amazon DynamoDBを使って状態管理したり、S3を使ってコンテナによって生成された成果物を保存したり、ということがロールによって可能であり、全てにおいてAWSの認証情報をコードの中に全く持つ必要がありません。 今までは、Amazon EC2のIAMロールを使う必要がありました。つまり、ECSクラスタのEC2インスタンスに紐付いたIAMポリシーは同一クラスタ内で実行されるタスクが必要な全てのIAMポリシーを含んでいる必要がありました。これは、もし1つのコンテナが特定のS3バケットへのアクセスが必要で、他のコンテナがDynamoDBテーブルへのアクセスが必要であった時、同一のEC2インスタンスに両方のIAM権限を与える必要があることを意味しています。 新しく公開されたECSタスクのためのIAMロールの導入によって、EC2コンテナインスタンスではなくECSタスクに直接IAMロールを紐付けることで、基盤をより安全に保つことができます。この手法によって、1つのタスクはS3にアクセスする特定のIAMロールを使いながら他のタスクはDynamoDBテーブルへにアクセスするIAMロールを使うことができます。 この機能によって、ECSクラスタインスタンスのIAMポリシーも最小限にすることが可能です。なぜなら、ECSサービスとやり取りするために必要な2,3のIAM権限を与えるだけで良いからです。 この記事で、タスクIAMロールのセットアップを眺めてみましょう。 必要条件 もしまだであればECSクラスタを作成し、最低でも1つのEC2インスタンスをクラスタ内に起動します。EC2インスタンスを起動するとき、Container instance IAM roleとして、AmazonEC2ContainerServiceforEC2RoleポリシーがアタッチされたIAMロールを選択します。 もし既存のクラスタがあれば、ECS最適AMIの2016.03.eを使い、この機能を使うために2016年7月13日リリースかそれより新しいSDKを使います。 デモンストレーション このデモでは、Amazon S3バケットを作成し’Hello World’ファイルをアップロードするだけの簡単なNode.jsアプリケーションを使います。アプリケーションのソースコードはaws-nodejs-sampleのGitHubレポジトリにあります。 Dockerイメージをビルドしプッシュする ターミナルアプリケーションで、以下のコマンドを実行します: $ git clone https://github.com/awslabs/aws-nodejs-sample すると現在のディレクトリの下にaws-nodejs-sampleという名前のディレクトリが作られ、サンプルアプリのコードが配置されます。そのディレクトリでDockerfileというファイルを作成し、以下のテキストを貼り付け保存します。 FROM node:argon # Create app directory RUN mkdir -p /usr/src/app WORKDIR /usr/src/app # Install app dependencies COPY package.json /usr/src/app/ RUN npm install # Bundle app source COPY […]

Read More

【AWS発表】新機能:Service Last Accessed Dataからのより詳細な情報取得

昨年末にAWS Identity and Access Management (IAM) で、IAMエンティティ(ユーザー、グループ、ロール)がAWSサービスに最後にアクセスした時刻を表示する機能としてService Last Accessed Dataをリリースしました。この機能は、最小限の権限付与に大きく役立つツールです。 本日、Service Last Accessed Dataの情報が追加され、どの権限を削除できるかをより簡単に識別することができるようになりました。 今回のリリースで、IAMエンティティとポリシーについて次のような情報にアクセスできます: マネージドポリシーやグループに関連付けられている全てのIAMユーザーおよびロールのLast Accessed Data あるIAMユーザー、ロール、グループに対して、サービスの権限を与えている全てのポリシー これらの追加された詳細データによってアクセスパターンやポリシー構成がより理解しやすくなります。結果として、より良い情報を元に権限管理の決断をくだせます。 この記事では、新しいより詳細なService Last Accessed Dataをウォークスルーし、どのように権限管理をより効果的に行うかについて説明します。   マネージドポリシーあるいはグループに関連付けられた全てのIAMユーザーおよびロールの最終アクセス履歴を参照する   あなたが、ユーザーやアプリケーションのセキュリティを管理する責任をもつIAMの管理者だと想像して下さい。全ての権限が必要ないIAMユーザーやロールに対して、ポリシーが広すぎる形で適用されていないかどうかを知りたいと思うことでしょう。これまでは、マネージドポリシーのアクセスアドバイザータブでは、サービスがいつ最後にアクセスされたかが表示されていましたが、どのユーザーあるいはロールが最後にアクセスしたのかを特定するためには、AWS CloudTrailのログをサーチする必要がありました。今回の機能によって、次のスナップショットに示すように、エンティティによるアクセス列のリンクをクリックすることにより、どのユーザーあるいはロールがそのサービスに最後にアクセスしたかだけではなく、そのサービスに関連付けられた全てのユーザーやロールがいつ最後にアクセスしたのかをすぐに見ることが出来るようになりました。   例えば、次のスクリーンショットは、あるマネージドポリシーで付与されているAmazon EC2の権限についての情報を表示しています。見ての通り、ポリシーをアタッチされている全てのユーザーやロールが実際にEC2にアクセスしているわけではありません。つまり、このユーザーやロールのうちの幾つかは、剥奪可能な過大な権限を持っていることを示しています。   あるユーザー、ロール、グループに対してサービスの権限を付与している全てのポリシーを参照する   さきほどと同じように、あなたが最小権限の原則を適用しようとしているIAM管理者であることを想像してください。あるユーザーやロールに対するService Last Accessed Dataを参照した後に、ユーザーやロールから必要ないポリシーを削除したりデタッチしたりしたいと思うかもしれません。この手助けとして、ユーザーのアクセスアドバイザータブで、どこで権限が付与されているかをクイックに見るために、ポリシーのアクセス権限内のサービス権限のリンクをクリックして下さい。そうすれば、AWS管理ポリシーやIAMグループから継承されたポリシーが表示されます。ダイアログボックスの中でポリシーの名前をクリックすることでそのポリシーを参照でき、簡単に変更を行うことが出来ます。   次のスクリーンショットは、あるIAMユーザーに付与されているEC2に対する権限のソースを示しています。見ての通り、複数のマネージドおよびインラインポリシーが定義されていて、幾つかのポリシーをクリーンナップあるいは統合する事が適切であるということを示唆しています。   Service Last Accessed Dataをより詳細に参照できる機能によって、権限管理がより容易になります。より詳細化されたService Last Accessed Dataについてコメントがある方は、下記のコメント欄にお願いします。ご質問のある方は、IAMフォーラムへの投稿をお願い致します。 – Zaher (翻訳はSA布目が担当しました。原文はこちら)

Read More