Amazon Web Services ブログ

Category: Learning Levels

AWS Config ルールの評価結果を Security Hub にインポートする方法

2019年6月の re:Inforce 2019 で、AWS は AWS Security Hub の正式リリースを発表しました。AWS Security Hubは、お客様がコンプライアンスチェックとセキュリティの評価結果を AWS アカウント間で共有し、一元的に表示、管理できるセキュリティサービスです。AWS Security Hub は AWS Guard Duty、Amazon Inspector、Amazon Macie、および 30 以上の AWS パートナーセキュリティソリューションからセキュリティ検出結果をインポートできます。 デフォルトでは、Security Hubが有効になると、CIS AWS Foundations がお客様のアカウントにデプロイされます。 CIS AWS Foundations は、AWS アカウントを強化するためのセキュリティ設定のベストプラクティスのセットです。Security Hub が CIS AWS Foundations に含まれているルールでコンプライアンスチェックを実行するためには、AWS Security Hub を有効にしたアカウントと同じアカウントで AWS Config を有効にする必要があります。 AWS Security Hub を有効にする前に、独自の AWS Config ルールを作成したことがある場合は、それらを AWS Security […]

Read More

AWS Security Hub PCI DSS v3.2.1 コンプライアンス標準の使用方法

2020年2月13日に、AWS は、AWS Security Hub に Payment Card Industry Data Security Standard (PCI DSS) バージョン 3.2.1 要件の部分的なサポートを追加しました。 この更新により、PCI DSS の要件のサブセットを検証でき、継続的かつ自動化されたチェックを実施することにより、進行中の PCI DSS 準拠の活動を支援します。新しい Security Hub コンプライアンス標準により、AWS リソースを積極的に監視することも容易になります。これは、カード会員データの保存、処理、または送信に関与する企業にとって重要です。また、Security Hub コンプライアンス標準のセキュリティスコア機能もあり、PCI DSS 評価の準備をサポートできます。

Read More

AWS Security Hubによる自動対応と修復

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 から必要なコンポーネントの大部分をデプロイします。

Read More

AWS CodeDeploy が Amazon ECS の線形デプロイと Canary デプロイをサポートするようになりました

 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 […]

Read More

Amazon Connect を使用して内線番号ベースのダイヤルソリューションを構築する方法

本投稿は 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 […]

Read More

VMware での AWS File Gateway の作成とアクティブ化

オンプレミスのアプリケーションが、変更を必要とせずに 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 […]

Read More

AWS でのゲノミクスワークフローに Amazon FSx for Lustre を使用する

  ゲノミクスのデータセットは、年々大きくなっています。世界中の研究イニシアチブからのデータを組み合わせ、それを迅速に処理する能力を持つことが重要な科学的発見を可能にするメカニズムとして重要であることが、大規模なバイオインフォマティクスおよびゲノミクスのコミュニティによって確認されています。グローバルな規模でのコラボレーションには、世界中からアクセス可能で、可用性が高く、高性能のデータ処理を可能にするデータストレージソリューションが必須です。 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 および […]

Read More

日本語版のホワイトペーパー公開: PCI DSS スコーピングおよび AWS 上でのセグメンテーションのためのアーキテクチャの設計

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 […]

Read More

S3 Same-Region Replication によるログの集約

  はじめに ログをセキュアな専用の場所に集約することは、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 […]

Read More

Amazon Athena を使った Amazon S3 分析データへのクエリ

最近、あるお客様からの問い合わせに答えました。その方々は、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 のレポートとそれぞれリンクするより、効率的に作業できます。 […]

Read More