Category: Amazon GuardDuty

Amazon GuardDuty は、悪意のあるアクティビティや不正な動作を継続的にモニタリングし、Amazon Simple Storage Service (Amazon S3) に保存されている AWS アカウント、ワークロード、データを保護する脅威検出サービスです。GuardDuty は、機械学習を活用した多数のパブリックデータフィードや AWS 生成データフィードから情報を得て、何かがおかしいという認識可能な兆候である傾向、パターン、異常を追跡し、何十億ものイベントを分析します。ワンクリックで有効にすると、数分で最初の結果を確認できます。 2022 年 1 月 21 日（米国時間）、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの認証情報が別の AWS アカウントから使用されていることを検出する機能を GuardDuty に追加しました。EC2 インスタンス認証情報は一時的な認証情報で、AWS Identity and Access Management (IAM) ロールがインスタンスに添付されたときに、EC2 メタデータサービスを通じてインスタンスで実行されているすべてのアプリケーションに対して提供されます。

*本投稿は原文 (2021年12月23日更新版) の日本語訳です 概要 この投稿では、最近公開された Log4j の脆弱性に対応しているお客様を支援するためのガイダンスを提供します。ここでは、脆弱性のリスクを制限するためにできること、問題の影響を受けやすいかどうかを特定する方法、適切なパッチでインフラストラクチャを更新するためにできることについて説明します。 Log4j の脆弱性（CVE-2021-44228、CVE-2021-45046）は、ユビキタスロギングプラットフォームの Apache Log4j における重大な脆弱性（CVSS 3.1 基本値 10.0）です。この脆弱性により、攻撃者は脆弱なプラットフォームでリモートでコードを実行する可能性があります。バージョン 2.0-beta-9 と 2.15.0 の間の Log4j のバージョン 2 が影響を受けます。 この脆弱性は、Java プログラムによって使用される Java Naming and Directory Interface (JNDI) を使用します。JNDI は、通常、ディレクトリ (この脆弱性の場合は LDAP ディレクトリ) を介してデータを検索します。 下の図 1 は、Log4j JNDI 攻撃フローを示しています。

みなさん、こんにちは。 アマゾン ウェブ サービス ジャパン、シニアエバンジェリストの亀田です。 Amazon GuardDutyが大阪リージョンで利用可能となりましたのでお知らせいたします。

本投稿では、商業銀行として米国で Top 25 内にランクインしている金融機関であるBBVA USAが、AWS サービスを使用して大規模なイベント管理の仕組みを実装し、クラウド環境に関連する変更イベントを一元管理し、アクションを自動化した方法について紹介しています。一般的に、モノリシック環境でのセキュリティ・コンプライアンスは、管理・監視対象となるインフラストラクチャが少ないため、監視と実施が比較的容易です。それが多くなったとしても、インフラストラクチャをコード化すれば、民主化され分散化されたアプローチによって、コンプライアンスの見落としなく構成の差分管理（ドリフト）と追跡処理を環境に取り入れることができます。 インフラストラクチャの正常な状態を識別し、そこから外れた違反状態を把握することにより、インフラの状態の可視性が確保され、必要に応じて自動修復によって遵守を強制させることが可能になります。このために、セキュリティイベントの通知やベースラインとなる構成定義といった機能を使うことができます。

みなさん、こんにちは。セキュリティ ソリューション アーキテクトの中島です。先日(2020年10月23日)にオープンソースで公開した SIEM on Amazon Elasticsearch Service (Amazon ES) をご紹介します。SIEM on Amazon ES は、セキュリティインシデントを調査するためのソリューションです。AWS のマルチアカウント環境下で、複数種類のログを収集し、ログの相関分析や可視化をすることができます。 SIEM on Amazon ES とは SIEM は Security Information and Event Management の略で、セキュリティ機器、ネットワーク機器、その他のあらゆる機器のデータを収集及び一元管理をして、相関分析によって脅威検出とインシデントレスポンスをサポートするためのソリューションです。Amazon ES は、オープンソースの Elasticsearch と Kibana を大規模かつ簡単でコスト効率の良い方法を使用してデプロイ、保護、実行する完全マネージド型サービスです。Amazon ES の環境に SIEM として必要な機能を実装したのが SIEM on Amazon ES です。

本投稿はワールドワイドで金融業界を担当しているプリンシパル・テクニカルプログラムマネージャーの Jennifer Code による寄稿を翻訳したものです。 私の同僚の Ilya Epshteyn が、 金融機関が機密性の高いデータのためにAWSサービスを承認する方法 というタイトルのブログでご紹介したように、金融業界では一般的にクラウドサービスの正式な評価プロセスが存在します。これらの評価プロセスは深さや幅に関しては様々ですが、いずれのプロセスも、業界の期待とテクノロジーリスク管理の健全性を確保しつつ、ビジネス要件を満たすのにはどのクラウドサービスが最適かを決定しようとするものです。このブログでは、クラウドサービスに対する新たな評価プロセスを構築する、または既存の評価プロセスを最適化する際に役立つシンプルなガイダンスを提供します。 私は、お客様と頻繁に会ってお客様のガバナンスとクラウドの評価プロセスについてディスカッションをしますが、その中でよく耳にするテーマがいくつかあります。１つ目は、評価プロセスが正式に存在する場合であっても、オーナー不在の場合が多く、結果としてそのプロセスが達成すべきビジネス上の成果を必ずしも理解しないまま、チームがプロセスに従っているという問題です。強いオーナーシップがなければ、参加者と評価範囲に一貫性が保てません。また、時には、構造化されたフレームワークではなく、個々の専門知識とベストエフォートに依存しているため機能性に差異が生じている場合もあります。最後に、お客様は、ほとんど例外なく、知識の共有を進めつつ、繰り返し学ぶことによって、評価プロセスの質を一気に向上させる方法があるのではと感じています。 正式なクラウドサービス評価プロセスがとても重要なのはなぜでしょうか? 金融サービス会社は、テクノロジーリスクの監視を証明するという、共通の規制上の義務を負っています。従来、企業のリスクフレームワークは、サイロ化された「3 つのラインによる防御」または (3LoD) で構成されていました。第一のラインはリスクの所有者としてコントロールを実行するビジネス / 運用担当者、第二のラインはリスクのモニタリングとコントロールの評価を行うリスク管理担当者、第三のラインは独立または内部監査人、またはリスクアシュランス担当者で構成されています。これらの 3LoD はそれぞれ、テクノロジーリスク、一般的な社内のポリシーの収集、ならびに他の防御ラインによって行われた一連の評価・監査に合わせて自チーム内で文書化された手順についての責任を負ってきました。 この既存の企業リスクフレームワークにクラウドの評価プロセスを組み込むことで、組織は重要な技術上の意思決定がどのように行われたかを適切に証明できるようになります。また、リスクがどのように評価され、軽減されるか、コントロール環境の強さがリスクアペタイトにどのように適合しているかといった点を、クラウドベースのサービスの微妙な差異に焦点を当てつつ説明できるようになります。 クラウド評価を最適化するためのヒント 金融サービスのお客様の期待を念頭に置き、お客様がクラウド評価プロセスを構築または改善するために実行できる3つのアクションを提案します。 ガバナンス体制の正式化。ガバナンス体制が正式に確立されていない場合、金融サービス機関がとるべき最初のステップは、クラウドのガバナンスとコントロールに関してエンドツーエンドの責任を担うC-レベルの経営幹部を任命することです。 プラットフォーム コントロールの優先順位付け。クラウド評価を策定する際に、優先順位と要件について、クラウド・プラットフォームとビジネス・アプリケーション機能の区分を取り入れます。セキュリティとレジリエンスのためのプラットフォームレベルのコントロールを最初の優先事項として重要視します。ビジネス・アプリケーションの機能に視点が移った時に、クラウドプラットフォームから継承されたコントロールに基づいて評価を調整できるようになります。 継続的な改善の組み込み。 知識共有と継続的な改善は、Day 1から明確に優先されるべきです。積極的な透明性があることにより、コントロールが構築され評価が行われる際に、3つの防御ラインすべてにわたっての信頼が築かれることが期待されます。意識的かつ積極的な共有によって、コントロールが設計されており、最初の本番ユースケースに対しても効率的に実行することができるという自信につながります。 AWSの使用量と専門知識が増えるにつれて、コントロールの強化と適用範囲の継続的な改善も容易になります。 ガバナンス体制の正式化 重要な最初のステップはクラウドのガバナンスに対する完全な説明責任を持つ適切な Cレベルの経営幹部を特定することです。この個人は、はじめにクラウドのガバナンスとコントロールのトーン設定を行い − クラウドの評価、使用状況、および継続的なモニタリングのための構造とプロセスを構築する責任をもちます。重要なのは、組織全体の専門知識を活用して、十分に制御されながらアジリティのある環境を確立するよう促す意欲のある、強力でポジションの高いリーダーを任命することです。 そのガバナンスのリーダーは任命され次第、評価プロセスを形成する機能横断的な構造、成文化されたポリシーと必要となるガバナンスプロセスを正式化し、現在進行中の評価のサポートをしなくてはなりません。私の経験では、正式なガバナンスの枠組みに支えられた多様な専門知識を活用できるバーチャルなチームが最も効果的です。 効果的なクラウドガバナンスの考慮事項 効果的なクラウドガバナンスの目標を定め、専門知識を正当に評価する企業全体のクラウド戦略 は、導入と使用状況を測定しながら時間をかけて構築します。 クラウドガバナンスに責任のある経営幹部を任命、従事、およびコミットすることで全体的なガバナンス構造に統合し、継続的なモニタリングを行います。 知識が豊富で 参加を約束できる（3 つの防御ラインにまたがった）リスクとコントロールのステークホルダーをクラウドのガバナンス活動における正式な参加者 にします。 企業のガバナンス フレームワークとプロセスに準拠することで、クラウドイネーブルメントチームの存在を明確にします。 定義されたプロセスを組織に伝達するとともに、承認されたクラウドサービスのみを利用していることを確実にする自動強制機能を使用します。 プラットフォーム コントロールの優先順位付け 私と顧客とのやり取りでよく見られたパターンは、クラウドサービスを評価するにあたり、たった１つのアプローチを作成し、それを全てのパターンに当てはめようとするやり方です。これは典型的に、各サービスを個別に評価する形式をとり、多くの場合、体系的に完成された詳細なチェックリストを伴います。 なぜこれが理想的ではないのでしょうか? 第一に、これは各サービスへの脅威は同等であることを前提としています（したがって、同じ評価が必要なコントロールを決定する適切な方法とされます）。第二に、このタイプのアプローチでは、評価者が能力または機能により区別することは認めていません（たとえば、データを中心としたサービスとコンピューティング サービスの違いを考慮しません）。最も重要な点は、既存の統制基盤を考慮していないことです（したがって、追加のコントロールの必要性を過大評価してしまう可能性があります）。 私が見てきた中で最も効果的だったのは、交渉不可能な基盤を確立した上で、環境、データの機密性、ビジネスの重要性など、他の要因に基づいて必要なコントロールを追加する、段階的なコントロール フレームワークです。この区分けによって、不適切なレベルのリスクを発生させることなく、実験を行うことができます。具体的には、すべてのデータタイプ、すべての環境において最初から予防的統制でなければならないコントロールもありますが、その他のコントロールではモニタリングをサポートすることによって、発見的統制から始めることが許容できるかもしれません。適切にコントロールされたイノベーションが目標です。 […]

今や仮想化は、クリエイティブな専門家が在宅勤務で仕事をする上で必要な環境となりました。本ブログでは、AWSクラウド上でポストプロダクションアプリケーションを実行する場合に重要な考慮事項を説明します。

2019年7月30日、AWS Loft Tokyo にて、AWS re:Inforce 2019 で発表・紹介されたセキュリティサービスやソリューションの最新情報を振り返るイベントが開催されました。 AWS re:Inforce 2019 とは、2019年6月25、26日に米国ボストンで開催された AWS セキュリティ&コンプライアンス最大のカンファレンスです。エンドユーザー様、パートナー様を中心に、世界50カ国以上中から8,000人以上の来場者が集まりました。基調講演や170を超えるセッション、パートナー様展示ブースからなる Security Learning Hub、参加者同士のネットワーキングイベントなどからなるとても大きなイベントでした。 そこで本セミナーでは、AWS re:Inforce 2019 に参加されたAWS利用者を迎え、企業のセキュリティ意思決定者・担当者に向けて効率的に情報収集いただく目的で開催されました。以下より、登壇者の発表から伝わる AWS re:Inforce 2019 の熱気をお感じください！

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）にアクセスを許可するには２つの選択肢があります。１つ目は、IAM サービスによって管理されるユーザー名とパスワードでログインする ID を作ることです。もう１つは、IDフェデレーションを利用して、既に企業の中に存在する認証情報を使って AWS コンソールや CLI にログインさせることです。それぞれのアプローチには異なるユースケースがあります。フェデレーションは、既に集中管理されたディレクトリがあるか、現在の制約である5000人以上の IAM […]

2018年12月20日、AWS Loft Tokyoにて、AWS re:Invent 2018で発表されたセキュリティ新サービスなど最新情報を振り返るイベントが開催されました。 AWS re:Invent 2018とは、2018年11月25日から11月30日まで米国ラスベガスで開催されたAWS最大のカンファレンスです。エンドユーザー様、パートナー様を中心に、世界中から50,000人以上の来場者、100,000以上のライブ参加者を集めました。re:Inventは、基調講演や2100を超えるブレイクアウトセッション、パートナー様ソリューション紹介、参加者同士のネットワーキングイベントなどからなります。期間中に発表された新サービスや機能アップデートは100を超えました。 そこで本イベントは、セキュリティ分野に絞り、企業のセキュリティ意思決定者・担当者に向けて効率的に情報収集いただく目的で開催されました。AWSソリューションアーキテクトによる新サービスアップデートに加えて、AWSに関わりの深いエンドユーザー様、パートナー様からAWSへの期待やAWSサービス使用時のGood Practiceを伝えていただきました！   第一部 AWS Threat Detection and Remediation Workshop 本イベントは二部構成で実施されました。第一部は新サービスAWS Security Hubを用いた実践的参加型ワークショップです。参加者は企業のセキュリティ管理者となり、AWS環境で構築しているWebサーバーを、外部脅威から保護します。複数のAWSサービスを駆使し、一早く脅威を検知し、詳細調査しながら、企業として適切なインシデント対応フローを構築します。 AWS Security Hub, Amazon GuardDuty, Amazon Macie, Amazon Inspector, Amazon CloudWatch, AWS Lambda, AWS Systems Manager, AWS Config, AWS Cloud Trail などのセキュリティサービスを講義で紹介しつつ、ハンズオンで実際触ってみて、最後に参加者自身がセキュリティ管理者だったらどのような脅威検知と対応の仕組を構築するかをディスカッションしました。 約40名の参加者からは、「実践的な内容のワークショップだったので、参考になりました。 会社でも実践してみたいと思います。」「ハンズオンで体験が出来良かったです。」「具体的に脅威へ対応する体験ができたのがよかったです」「セキュリティの設定や実際の攻撃を体験することが出来、大変参考になりました。」「実践的な流れで体験したことでそれぞれの機能の概要が、短時間で理解できた気がします。」「実際にサービスを触りながら学ぶことができたので良かったです。」「AWSセキュリティ体系の重要性と勉強の必要性を多分に感じました。」などの声をいただきました。 今後もAWS Loft Tokyoなどで同ワークショップを開催していきますので、是非ご参加ください！   第二部 AWS re:Invent 2018 Security re:Cap […]