Category: Security

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

  皆様、こんにちは。セキュリティソリューションアーキテクトの桐山です。 2018/10/29(月)から11/2(金)にかけて開催されたAWS Dev Day Tokyo 2018で実施された、セキュリティ関連のセッションとワークショップをおさらいしてみます。 開発者向けカンファレンスということで、この度はセキュリティに興味のある多くの開発者にご参加いただきました。これから企業がデジタルトランスフォーメーション(DX)時代に向かっていく中、開発者の役割も更に高度化・専門化しています。 事業部門で、いわゆるSysmem of Engagement(SoE)領域に携わる開発者は、下記のような今までにない新しいワークロードをセキュアに開発することに挑戦しているでしょう。 IoTサービスにより、様々なデバイスから大量の信頼性の高い実データを収集する 企業内データを一元的に集約・保存する場所(データレイク)をセキュアに管理・運用する 迅速にビジネスインサイトを活用するために、データ分析・可視化・利用をサーバーレスコンピューティング環境で実現する 上のそれぞれに相当するIoTセキュリティ、データレイクセキュリティ、サーバーレスセキュリティは新しいセキュリティ技術領域と言えます。 一方で、IT部門にて、いわゆるSystems of Record(SoR)領域に携わる開発者は、事業成長を支えるセキュリティ基盤を実現しなければなりません。ITインフラ自体を変革させると同時に、事業活動の変化やスピードに対応するためにSecurity as a ServiceやSecurity Automationに取り組むことになるでしょう。 このようなDX時代のセキュリティをAWSで実現するとしたら・・・以下のワークショップとセッションが役に立つはずです。

セキュリティは、AWS の最優先事項です。AWS は、お客様のデータを保護することを何よりも重視しており、お客様のフィードバックを AWS サービスに継続的に取り入れ、迅速なイノベーションに取り組んでいます。お客様に AWS のこうした取り組みについて、よりご理解いただくために、この度、AWS のセキュリティやコンプライアンスについて紹介する動画の公開を開始しました。   ・AWS の責任共有モデルのご紹介動画 IT インフラストラクチャーを AWS に移行する際は、責任共有モデルを考慮いただく必要があります。AWS の責任範囲はクラウド環境自体のセキュリティ、お客様の責任範囲はクラウド環境上のセキュリティとなります。お客様は、お客様のシステムと全く同じように、コンテンツ、プラットフォーム、アプリケーション、システム、ネットワークを保護するためのセキュリティを設計いただく必要があります。AWS の責任共有モデルについては、下記よりご視聴ください。     ・AWS のデータセンターのご紹介動画 AWS は AWS のデータセンターのデジタルなツアーを既に公開していますが、AWS のデータセンターの一部についてツアーのようにご覧いただける動画をお客様に公開いたしました。AWS は自然災害や人為的なリスク等から AWS のインフラストラクチャーを保護するための AWS のデータセンターシステムについて、継続したイノベーションに取り組んでいます。膨大な数の実際にご利用いただいているお客様を保護するためのセキュリティ上の取り組みについて紹介しておりますので、下記よりご視聴ください。     ・Amazon GuardDuty のご紹介動画 Amazon GuardDuty は、インテリジェントな脅威検出サービスとなり、悪意のある操作や不正な動作に対してAWS アカウントおよびワークロードを継続的に監視します。Amazon GuardDuty について紹介しておりますので、下記よりご視聴ください。     ・Amazon Inspector Amazon Inspector は、AWS に展開されたアプリケーションのセキュリティとコンプライアンスを向上させるための、自動化されたセキュリティ評価サービスです。脆弱性やベストプラクティスから優先順位付けしたセキュリティに関する所見の詳細リストを生成します。Amazon Inspector について紹介しておりますので、下記よりご視聴ください。     – […]

日本時間 2018年6月13日 03:00 インメモリデータストアであるRedisのセキュリティアドバイザリが公開されました。Amazon ElastiCache によって管理される Redis互換のノードは、単一のエンジンが稼働する、お客様の VPC で独立したお客様専用のノードです。したがって、VPC の設定で明示的に許可されていない限りは、他のお客様がそれらのノードに対しアクセスすることはできません。 Amazon ElastiCache においても、アップデートを含む新しい Redis バージョンがリリースされました。2018年6月10日以降に起動された ElastiCache クラスターには、影響はありません。既存の ElastiCache クラスターをお持ちのお客様は、メンテナンスウィンドウにて新しいバージョンへのアップデートが予定され、順次実施されます。このアップデ―トは今回の問題に完全に対処できるよう設計されており、ElastiCache はデフォルトで意図しない外部からのアクセスを防ぎます。このアップデートに関して、お客様によるアクションは必要ありません。 本件に関してセキュリティの懸念がある場合は、http://antirez.com/news/119 をご覧ください。また、Amazon ElastiCache クラスターへのネットワークアクセスをセキュアに保つ方法は、”Amazon VPCs and ElastiCache Security”[1] をご覧ください。 [1]: https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/VPCs.html   上記はAWS Japan Security Awareness Teamによって翻訳されました。原文は以下です： https://aws.amazon.com/jp/security/security-bulletins/AWS-2018-016/

アプリケーションやフェデレーションされたユーザーが長時間実行の必要なワークロードを単一のセッションで完了できるように、IAM ロールの最大セッション時間を 12 時間まで延長できるようになりました。ユーザーおよびアプリケーションはこれまで通り AWS Security Token Service (AWS STS) を使ってロールを引き受けつつも、AWS SDK または CLI で取得した一時的な認証情報の有効期間が最大 12 時間となるようにできます。この変更により、ユーザーやアプリケーションは、S3 への大量アップロードやCloudFormation テンプレートといった長時間実行が必要なワークロードを、単一のセッションで実行できるようになります。最大セッション期間の延長は、IAM コンソール、または CLI で行えます。最大セッション期間を延長すると、対象の IAM ロールを引き受けているユーザーやアプリケーションが次に一時的な認証情報をリクエストした際には延長された有効期限の認証情報が得られるようになります。 本ブログ記事では、IAM コンソールを使用して、既存の IAM ロールの最大セッション期間を 4 時間 (設定可能な最大期間は 12 時間) に設定する方法をご紹介します。4 時間にする理由は、AWS では、ロールのセッション期間を設定する場合、フェデレーションされたユーザーが AWS リソースへのアクセスを最低限必要と思われる期間に設定することを推奨しているためです。次に、既存のフェデレーションされたユーザーが、AWS SDK や CLI を使用して、ロールのセッションの有効期限が切れると失効する一時的なセキュリティ認証情報をリクエストする方法についてご説明します。 前提条件 本ブログ記事では、フェデレーションの例を使用します。既存の ID プロバイダーがある場合は、SAML (Security Assertion Markup Language) を使ったフェデレーションを有効にして、ユーザーによる AWS リソースへのアクセスを許可している方もおられると思います。本ブログ記事では、フェデレーションされたユーザーの権限を定義する外部 ID プロバイダー用の […]

  2018年4月30日 より、Google Chrome は全ての公式に信頼する証明書は少なくても 2 箇所の Certificate Transparency ログに記録されている事を必須条件とします。これにより Google Chrome ではログに記録されていない発行済の証明書にはエラーメッセージが表示される事になります。2018年4月24日より、お客様が Certificate Transparency ログへの記録を無効にしない限り、アマゾンは全ての新規や更新した証明書について少なくても 2 箇所以上の公開ログに記録を行うようにします。 Certificate Transparency ログが無い場合、所有するドメイン名に対する予期しない証明書発行を把握することは難しいでしょう。現行システムでは、発行された証明書の記録は保管されておらず、ドメインの所有者は不正な証明書を見つける信頼性のある方法はありませんでした。 この状況に対処するために、Certificate Transparency は発行された各証明書についての暗号化技術による安全なログを実現します。ドメインの所有者は間違いや悪意で発行されたものも含め、予期しない証明書を見つけるためにログを検索することができます。また、ドメインの所有者は不適切に証明書を発行している認証局 (CA) を見つける事も可能です。このブログ記事では、Certificate Transparency についてより詳細に説明し、どうやって準備をすればよいのかお伝えします。

ネットワークストレステスト 【日本語訳】日本時間 2018年02月08日09:00 このポリシーは、お客様の Amazon EC2 インスタンスから、他の Amazon EC2 インスタンス、AWS プロパティ/サービス、外部エンドポイントのような他の場所へ、大規模なネットワークテストを直接実施することを計画しているお客様に関係するものです。 これらのテストは、ストレステストや負荷テスト、ゲームデーテストと呼ばれることがあります。このポリシーでは、テストにおいて正当な大規模トラフィックあるいはテストトラフィックを特定の対象アプリケーションに対し送信する行為を「ネットワークストレステスト」とします。エンドポイントとインフラストラクチャは、このトラフィックを処理できる必要があります。 このポリシーは、通常のプロダクションのトラフィックとは関係ありません。ネットワークストレステストは、多くの場合、特定のエンドポイントを対象とし、送信元や対象が集中することを含め、通常とは異なるトラフィックパターンを持ち、持続的に大規模なトラフィックが発生し、予期している上限値を超える可能性があるため、通常のプロダクションとは異なります。ネットワークストレステストにおけるこれらの違いは、外部エンドポイント、他のお客様、AWS サービスに対し意図しない影響を与えうる潜在的なリスクとなります。 パケットや接続のフラッディング、それ以外の大規模なトラフィックで、ターゲットやインフラストラクチャへ意図的に過大な負荷をかけるテストは、ネットワークストレステストではなく、分散型 DoS (DDoS) テストとして扱われます。ボリュームのあるネットワークベースの DDoS シミュレーションは、Amazon EC2 プラットフォームでは明示的に禁止されています。このポリシーは、https://aws.amazon.com/security/penetration-testing の範囲のセキュリティやペネトレーションテストは対象としません。 ほとんどのお客様はこのポリシーには該当しません。通常、ユニットテストのように大規模なワークロードをシミュレートするストレステストでは、ネットワークストレステストに該当するだけのトラフィックは生成されません。このポリシーは、お客様のネットワークストレステストによって、Amazon EC2 インスタンスで以下の基準を満たすトラフィックが生成されたときに適用されます。”持続的に 1分以上の間 1 Gbps（秒間 1億ビット）あるいは 1Gpps（秒間 1億パケット）を超えるトラフィック、悪用目的や悪意があるように見えるトラフィック、テスト対象以外（ルーティングや共有サービスのインフラストラクチャなど）へ潜在的に影響を及ぼしうるトラフィック” などが該当します。 お客様は、対象のエンドポイントへのテストが承認され、その起こりうる規模について理解している必要があります。いくつかの外部エンドポイントや AWS サービスは、ある種のテストシナリオに対して期待する閾値よりも低い性能しか発揮できない可能性があります。 AWS を利用する多くのお客様は通常のプロダクションモードで定期的に 1Gbps もしくは 1Gpps 以上のトラフィックを生成していることを確認しております。これは完全に正常であり、特にネットワークストレステストの目的のために実施されたものではない限り、このポリシーの範囲下ではありません。 このポリシーの基準を満たすネットワークストレステストにはリスクがあります。お客様が悪質であると検知され報告されるリスク、お客様が意図せず悪質となり他の対象に影響を及ぼすリスク、お客様が所有するインスタンスで機能制限を受ける可能性などがあり、この際にはテストだけではなく、プロダクションのワークロードへ影響する可能性があります。 実施するテストがこれらの基準を満たすか、お客様で不明な場合は、このポリシーに従い、AWS 側にテストの評価を依頼する必要があります。お客様の体験や、その他の影響を受ける可能性があるサービスを改善していくため、これらのストレステストを実行する前には、Amazon EC2 ネットワークストレステストを申し込みフォームから申請してください。このフォームは aws-security-simulated-event@amazon.com へメールを送ることで入手できます。 お客様のネットワークストレステストが 外部や他の AWS サービスのような EC2 インスタンス以外から直接実行される場合、フォームからの申請が必要かどうかメールでお問い合わせください。 […]

モダンコンピュータプロセッサ上で投機的実行によるサイドチャネル分析の調査が新しく公開されたのを受け、AWS は AWS Security Bulletin（セキュリティ情報）AWS-2018-013 を先日公開しました。このセキュリティ情報では、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 の3つのセキュリティ勧告に触れています。これらの勧告は Google Project Zero の調査に基づいたもので、Google Project Zero の発表はモダンコンピュータプロセッサ上でのサイドチャネル分析の新しい方法を発見したというものでした。これらの方法は、基礎的な技術、具体的には投機的実行に着目したもので、投機的実行は多くのベンダーのプロセッサに用いられています。そのため研究結果の対象となる範囲は幅広く、その範囲はハイパーバイザーからオペレーティングシステム、さらには Web ブラウザ、携帯電話からクラウドを構成するデータセンター内のサーバにまで及びます。   EC2 インスタンスの分離   Amazon EC2 のすべてのインスタンスは、上述の CVE に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 大多数の EC2 ワークロードに有意なパフォーマンスの影響は見られていません。   オペレーティングシステムへのパッチ   現代のオペレーティングシステムには、「ユーザー空間」プロセスからのカーネル分離、それぞれのプロセスの分離などの、いくつかのタイプのプロセス分離があります。影響を受けうるプロセッサ上でオペレーティングシステムが実行されている環境では、いかなる設定においても、公開された 3 つの問題すべてがプロセス分離に影響を与える可能性があります。ハイパーバイザで実装されている保護は、オペレーティングシステム内のプロセスレベルの分離にまで拡張されないため、リスクを軽減するためにオペレーティングシステムパッチが必要です。 準仮想化（PV）インスタンスでは、CVE-2017-5754 のプロセス間の問題に対処するためのオペレーティングシステムレベルの保護は無いことに注意してください。PV インスタンスは、前述のようにインスタンス間の問題について AWS ハイパーバイザーによって保護されます。しかしながら、PV インスタンスにおけるプロセスの分離（信頼できないデータ処理やコードの実行、ユーザのホスト）にご懸念をお持ちでしたら、長期的に見てセキュリティの恩恵を受けるため、HVM インスタンスタイプへの変更を強くお勧めします。PVとHVMの相違点（およびインスタンスアップグレードパスのドキュメント）の詳細については、以下の URL を参照してください。 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html インスタンスのオペレーティングシステムにパッチを適用することで、同じインスタンス内で動作するソフトウェアを分離し、CVE-2017-5754 のプロセス間の問題を緩和することを強く推奨します。以下のオペレーティングシステムのパッチの詳細を記載します。 Amazon Linux & […]

【日本語訳】日本時間 2018年02月14日19:30 関連する CVE: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 日本時間 2018年02月06日09:30 以下は本件に関するアップデートです。 Amazon Linux 用の更新されたカーネルは、Amazon Linux のリポジトリにて入手できます。2018年1月13日以降にデフォルトの Amazon Linux 設定で起動された EC2 インスタンスには自動的に最新のパッケージが含まれています。 最新のパッケージでは、 CVE-2017-5715 に対処するための安定版オープンソース Linux セキュリティの改善がカーネル内に組み込まれています。また 以前取り込まれた CVE-2017-5754 に対処するカーネルページテーブルアイソレーション（KPTI）にもとづいて作成されています。インスタンス内の CVE-2017-5715 のプロセスープロセス間の問題と CVE-2017-5754 のプロセスーカーネル間の問題を効果的に軽減するには、最新の Amazon Linux カーネルまたは AMI にアップグレードする必要があります。詳細は「プロセッサの投機的実行 – オペレーティングシステムの更新」を参照してください。 para-virtualized（PV）インスタンスについては、以下の「PV インスタンスガイダンス」の情報を参照してください。   Amazon EC2   Amazon EC2 のすべてのインスタンスは、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 […]