Category: Learning Levels

AWS Security Hub は、複数の AWS アカウントにわたるセキュリティとコンプライアンスの状態を可視化するサービスです。AWS のサービスおよび APN パートナーソリューションからの検出結果を処理することに加えて、Security Hub にはカスタムアクションを作成するオプションがあり、お客様は特定の検出結果に対して特定の対応と修復アクションを手動で呼び出すことができます。カスタムアクションは特定のイベントパターンとして Amazon CloudWatch Events に送信されます。CloudWatch Events ルールは、Lambda 関数や Amazon SQS キューなどのターゲットサービスをトリガーできます。 特定の検出結果タイプにマッピングされたカスタムアクションを作成し、そのカスタムアクションに対応する Lambda 関数を作成することにより、これらの検出結果のターゲットを絞った自動修復を実現できます。これにより、お客様は特定の検出結果に対して何の修復アクションを呼び出すかどうかを明確にできます。お客様は、これらの Lambda 関数を、人が介在しない完全に自動化された修復アクションとして使用することもできます。 本ブログでは、カスタムアクション、CloudWatch Events ルール、および Lambda 関数を作成する方法を紹介します。これらによって、CIS AWS Foundations ベンチマークの十数個のコンプライアンス検出結果を修復できます。また、検出結果を課題管理システムに送信し、セキュリティパッチを自動化するユースケースについても説明します。このソリューションをお客様がすぐにご利用できるように、AWS CloudFormation から必要なコンポーネントの大部分をデプロイします。

 AWS CodeDeploy は、Elastic Container Service (Amazon ECS) のブルー/グリーンデプロイサポートを拡張し、AWS Fargate または Amazon Compute Cloud (Amazon EC2) でホストされるアプリケーションの Canary および線形デプロイを含めます。 ブルー/グリーンデプロイは、アプリケーションバージョンの変更による中断を最小限に抑えるために、AWS CodeDeploy が提供する安全なデプロイ戦略です。これは、グリーンと呼ばれる新しいアプリケーション環境と、ブルーと呼ばれるライブトラフィックを処理している現在のアプリケーションを作成することによって実現されます。これにより、ライブトラフィックがブルーからグリーンにルーティングされます。その後、ブルーのリソースがオフになる前に、グリーンの環境を監視およびテストするための一定期間が許可されます。 Amazon ECS のブルー/グリーンデプロイを最初に立ち上げた後、多くのお客様は、アプリケーションの更新によって一定期間にわたって変化するトラフィックの量を制御することに関心を示しました。  CodeDeploy を介した線形デプロイと Canary デプロイでは、新しいアプリケーションバージョンへのライブトラフィックの露出をトラフィック全体のパーセンテージに制限することで実現し、残りのトラフィックをルーティングする前にパフォーマンスを監視します。Amazon CloudWatch アラームを設定することもできます。問題が検出された場合、CodeDeploy は自動的にトラフィックルーティングを元のバージョンに戻します。  CodeDeploy は、ALB の加重ターゲットグループを使用してこれを実現します。 この記事では、Fargate でホストされる Amazon ECS の新しい線形デプロイと Canary デプロイを構成する方法を示します。 今日は次の内容を行います。 CodeDeploy をコントローラとして ECS サービスを作成する 新しい線形構成を使用して新しいデプロイグループを作成する 1 分ごとにトラフィックの 10% をルーティングするためのプリセット線形デプロイ構成を使用して、CodeDeploy ブルー/グリーンデプロイをトリガーします。 現在、次の事前定義された線形および Canary […]

本投稿は Connect Specialist SA の Sayed Hassan による寄稿を翻訳したものです。 コンタクトセンターでは、発信者が特定のエージェント（担当者）に直接かけられるよう、各エージェントに内線番号を割り当てることが一般的に行われています（訳注：米国の場合）。これにより、各エージェントに 直通電話番号（ダイヤルイン） を割り当てる必要性が低減されます。応答可能なエージェントに顧客がランダムに割り当てられるのではなく、希望するエージェントと直接話したいアカウント管理シナリオでは、顧客がエージェントに直接かけられるようにするのが一般的です。本投稿では、このようなビジネス上のユースケースを解決するために、Amazon Connect を使った内線番号ベースのダイヤリングの仕組みを見ていきます。 内線番号ベースのダイヤルソリューションを構築するには、Amazon Connect、AWS Identity and Access Management (IAM) ロール、Amazon DynamoDB テーブル、AWS Lambda 関数を含む AWS サービスを使用します。 概要 このソリューションを構築するには、次のステップを実行します。 1.   内線番号とエージェントID間のマッピングを保持する DynamoDB テーブルを作成します。 2.   Lambda 関数が DynamoDB 内のエージェント ID を参照できる IAM ロールを作成します。 3.   実際の検索用の Lambda 関数を作成します。 4.   Amazon Connect に Lambda 関数を追加します。 5.   Lambda 関数を実行する問い合わせフローを作成します。 前提条件 このソリューションを構築するには、Amazon Connect インスタンスをプロビジョニングし、エージェントを作成する必要があります。詳細については、Amazon […]

オンプレミスのアプリケーションが、変更を必要とせずに AWS Cloud Storage を使用できたらすばらしいと思いませんか？ SMB や NFS などの標準のファイルストレージプロトコルを使用しますか？ その場合、AWS Storage Gateway の一部である File Gateway を使用できます。 File Gateway は、オンプレミスアプリケーションの SMB または NFS ファイル共有を表し、ファイルを Amazon Simple Storage (Amazon S3)オブジェクトとして保存し、従来のファイルインターフェイスでそれらにアクセスします。File Gateway を使用すると、NFS または SMB 共有をバックアップアプリケーションのネットワークパスとしてマッピングし、オンプレミスから Amazon S3 にデータをバックアップできます。 File Gateway は、VMware ESXi または Microsoft Hyper-V ハイパーバイザーを使用する仮想マシン (VM)としてオンプレミス環境にデプロイできます。このブログでは、ファイルゲートウェイ OVA イメージを VMware ESXi ハイパーバイザー上の VM としてデプロイする手順を説明します。AWS マネジメントコンソールから VM イメージをダウンロードして、ファイルゲートウェイの作成を開始します。VM […]

  ゲノミクスのデータセットは、年々大きくなっています。世界中の研究イニシアチブからのデータを組み合わせ、それを迅速に処理する能力を持つことが重要な科学的発見を可能にするメカニズムとして重要であることが、大規模なバイオインフォマティクスおよびゲノミクスのコミュニティによって確認されています。グローバルな規模でのコラボレーションには、世界中からアクセス可能で、可用性が高く、高性能のデータ処理を可能にするデータストレージソリューションが必須です。 Amazon FSx for Lustre は、高性能 POSIX 準拠の共有ファイルシステムの使いやすさと、Amazon Simple Storage Service (Amazon S3) の業界をリードするスケーラビリティとデータ可用性を兼ね備えています。Amazon FSx for Lustre は Amazon S3 とネイティブに連携し、S3 オブジェクトをファイルとして透過的に提示するため、高性能ファイルシステムでクラウドデータセットを処理し、結果を S3 に書き戻すことが簡単になります。データを Amazon S3 に保存することで、Amazon Redshift、Amazon Athena、Amazon EMR、Amazon SageMaker などの分析および機械学習のソリューションによるダウンストリーム分析が可能になります。 このブログ記事では、Amazon FSx for Lustre を簡単に使用して、AWS でのゲノミクスワークフローを簡素化および高速化する方法を示します。 ゲノミクスワークフロー ゲノミクスワークフローは通常、ファイルの操作用に設計された複数のコマンドラインツールで構成されています。つまり、入力として FASTQ や BAM などのファイルを受け取り、出力として TSV/CSV や VCF などのファイルを生成します。 私たちが使用するゲノミクスワークフローは、二次解析パイプラインです。この特定のパイプラインは、コンテナ化されたツールのセットを使用して、未加工の全ゲノム配列を変形 (標準リファレンスと比較した配列の違い) に変換します。 以前のブログ記事投稿で、AWS Batch および […]

AWS は、AWS クラウドで実行する Payment Card Industry (PCI) Data Security Standard (DSS) のワークロードの適用範囲を適切に定義するためのガイドとして、PCI DSS スコーピングおよび AWS 上でのセグメンテーションのためのアーキテクチャの設計の日本語版のホワイトペーパーを公開しました。このホワイトペーパーは、クラウドネイティブの AWS サービスを利用するスコープ内のリソースとスコープ外のリソース間のセグメンテーションの境界を定義する方法について説明しています。 このホワイトペーパーの対象読者は技術者とソリューション開発者ですが、認定審査機関 (Qualified Security Assessors、QSA) および認定内部監査人(Internal Security Assessors、ISA) が AWS の製品とサービスで使用できる様々なセグメンテーション制御およびそれに関連するスコープ設定の考慮事項に関する理解を深めるガイドとしても利用できます。 AWS のソフトウェアで定義されたネットワークでは、ネットワークのセグメンテーションを超えた追加のセグメンテーション制御が可能なので、アプリケーションのスコープ設定プロセスがオンプレミス環境の場合と異なります。アプリケーションの設計およびセキュリティに影響するサービスの選択を慎重に考慮して必要な制御を実装すれば、カード会員データ環境 (Cardholder Data Environment、CDE) のシステム数とサービス数を減らせます。 このホワイトペーパーは PCI 協議会の Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation に基づいています。 Avik Mukherjee Avik は IT ガバナンス、セキュリティ、リスク、コンプライアンスの分野で 10 […]

  はじめに ログをセキュアな専用の場所に集約することは、SIEM (セキュリティ情報イベント管理) といった極めて重要な操作を効率化します。より多くのお客様がマルチアカウント戦略を導入している中、一元的なログ記録は運用上の優秀性 (オペレーショナルエクセレンス) を推進する主要要素となっています。そのメリットを考慮して、エンタープライズのお客様はしばしば複雑なサードパーティーツールと使って一元的なログ集約ソリューションを構築します。Amazon S3 Same-Region Replication (SRR) の発表に伴い、お客様はログ集約を含めた数多くのユースケースにこの機能を使用できるようになります。S3 SRR は S3 レプリケーションの機能で、同じ AWS リージョン内にあるバケット間でデータを自動的にレプリケートします。SRR は、特定のバケットまたはプレフィックスにアップロードされた新しいオブジェクトをレプリケートするように設定できます。また、SRR は特定のタグが付けられた新しいオブジェクトを、ユーザーが選択するレプリケーション先にレプリケートすることもできます。お客様は、単一のアカウントまたは複数のアカウントによって所有されている異なる S3 バケットからのログを、今後の処理のために一元化された 1 つのバケットに集約するように SRR を使用することも可能です。 このブログ記事では、S3 SRR を使ってマルチアカウントランドスケープでホストされている VPC からの VPC フローログを収集することによって、ログ集約のデモを行っていきます。今回のセットアップでは、このチュートリアル用に 2 つの AWS アカウント (アカウント A とアカウント B) を使用しますが、シングルアカウントシナリオでのデータ集約にも同じ原則が当てはまります。このセットアップでは、VPC フローログを生成するアカウントをアカウント A、集約されたログバケットをホストするアカウントをアカウント B と呼びます。 前提条件 S3 Same-Region Replication をセットアップするためのステップバイステップガイドを掘り下げていく前に、前提条件を確認しましょう。 アカウント A の前提条件 VPC […]

最近、あるお客様からの問い合わせに答えました。その方々は、S3 Standard、S3 Infrequent-Access、そして S3 One-Zone Infrequent-Access など、複数ある Amazon S3 ストレージクラスに価値を感じているものの、そのストレージを最適化するのに、どの階層とライフサイクルルールを適用してよいか迷っているということでした。このお客様を含め、同様な状況にある他の方々も、複数のバケットと、各種のデータアクセスパターンを使用されています。結局、当社とお客様で協力しあい、S3 Analytics レポートが利用できるようにし、最適なライフサイクルが容易に決定できるようになりました。今回のブログ記事では、この過程で我々が学んだことや、多くの分析レポートを一度に簡単に調べるためのテクニックなどについて、概要をご説明していきます。 2016 年 11 月にリリースされた Amazon S3 分析 では、ストレージへのアクセスパターンの分析や、適切なデータを適切なストレージクラスへ移動させる機能などが提供されました。また、分析を行うためのデータを S3 バケットへ手動でエクスポートすることも可能になりました。これで、好みのビジネスインテリジェンスツールが使用でき、利用率や増加パターンについてより深い洞察を集めることができます。この機能は、利用パターンに基づきパフォーマンスを最適化しながら、ストレージのコストを削減するために役立ちます。 また、Amazon QuickSight の更新が 2017 年の 11 月に行われました。S3 コンソールでの数回のクリックにより、この QuickSight が、特定の S3 バケットに関する S3 分析を視覚化できるようにします。この処理は、手動でのエクスポートやデータに関する余計な準備作業も必要なく自動で完了します。 本記事では、こういったアナリティクスレポートのレビューをするための、代替的な方法をご紹介していきます。今回の手法では、サーバーレスで双方向性のクエリサービスである Amazon Athena、そして、完全マネージド型の ETL (エクストラクト、トランスフォーム、ロード) とデータカタログのサービスを提供する AWS Glue を使います。これらのサービスを併用することで、S3 Analytics レポートに対し直接 SQL クエリできます。QuickSight やその他のデータベースエンジンにロードする必要はありません。 この手法により、ストレージクラスのコスト削減方法が、一度にすべてのバケットに関して素早く簡単に特定できるようになります。Amazon S3 内で個別のレポートを調査したり、そのレポートを QuickSight のレポートとそれぞれリンクするより、効率的に作業できます。 […]

AWS re:Invent 2019 では、多くの発表や機能の開始がありました。そうした中で、AWS ストレージユーザー向けの今後の可能性に関する発表の 1 つが、AWS Local Zones に関するものでした。現在のところ、このニュースは特にロサンゼルス近郊でハイパフォーマンスのアプリケーションを実行している Amazon FSx および Amazon Elastic Block Store (Amazon EBS) のお客様に関連しています。 新しいタイプの AWS インフラストラクチャのデプロイメントとして、AWS Local Zones は、現在 AWS リージョンが存在しない大規模な集団、産業、IT センターの近くに選択したサービスを配置するのに役立ちます。Local Zones を使用すると、アプリケーションのレイテンシーに敏感な部分を、簡単に特定の地域のエンドユーザーおよびリソースに対してローカルで実行できます。これにより、メディアおよびエンターテインメントのコンテンツ制作、リアルタイムゲーム、油層シミュレーション、電子設計の自動化、機械学習などのユースケースで非常に低いレイテンシー (ミリ秒 1 桁) を実現できます。 それぞれの Local Zone は、アプリケーションが Amazon FSx や Amazon EBS などの AWS のサービスを使用する AWS リージョンの拡張です。たとえば、Amazon FSx を使用するレイテンシーの影響を受けやすいアプリケーションでは、ローカルワークロードと近接する AWS リージョンで実行されているワークロードとの間の高帯域幅で安全な接続を活用できます。これにより、同じ API とツールセットを使用して、AWS […]

10 年以上前にリリースして以来、Amazon EC2 インスタンスメタデータサービス ( IMDS ) は、安全でスケーラブルなアプリケーションの構築を支援してきました。IMDS は、一時的な認証情報へのアクセスを提供することで、クラウドユーザーにとって大きなセキュリティ上の課題を解決し、手動またはプログラムによってインスタンスに機密認証情報をハードコードしたり、配布したりする必要をなくしました。EC2 インスタンスにアタッチされた IMDS は、特別な「リンクローカル」の IP アドレス 169.254.169.254 で接続され、インスタンスで実行中のソフトウェアだけがアクセスできます。アプリケーションは IMDS にアクセスして、インスタンス、ネットワーク、およびストレージに関するメタデータを利用できます。また、IMDS は、インスタンスにアタッチされている IAM ロール による AWS 認証情報を使用できるようにします。 クラウドでアプリケーションを実行する場合、アプリケーションのセキュリティはインスタンスのセキュリティと同様に重要です。インスタンスで実行されているアプリケーションに脆弱性や設定ミスがあると、重大な問題が生じる可能性があります。アプリケーションセキュリティは多層防御において重要な役割を果たしますが、AWS はインスタンス内であっても、このような状況による被害の可能性を最小限に抑えるために、防御レイヤーを追加する場所をいつも検討しています。 本日、EC2 インスタンスメタデータサービスの v2（ IMDSv2 ）が利用可能になりました。既存のインスタンスメタデータサービス（ IMDSv1 ）は完全にセキュアであり、こちらも引き続きサポートします。しかし、IMDSv2 は、IMDS へのアクセスを試みる可能性がある４種類の脆弱性に対して新しい保護を追加します。この新しい保護は、IAM ロールの制限や、ローカルファイアウォールのルールを使用した IMDS へのアクセス制御など、既存の緩和策とシームレスに連携しますが、これらの緩和策よりも効果的に機能します。また、IMDSv2 をサポートする新しいバージョンの AWS SDK および CLI も利用可能です。 IMDSv2 の新機能 IMDSv2 では、すべてのリクエストがセッション認証によって保護されるようになりました。このセッションは、EC2 インスタンスで実行中のソフトウェアがリクエストするもので、ローカルに保存されている EC2 インスタンスのメタデータと認証情報にアクセスするためのものです。ソフトウェアは、IMDSv2 への単純な HTTP PUT リクエストを使用してセッションを開始します。IMDSv2 […]