Amazon Web Services ブログ

Category: Foundational (100)

re:Invent – これから予定されるセキュリティセッション

本投稿は、 AWS Security のシニアプログラムマネージャーである Maria Taggart による寄稿を翻訳したものです。 先月のAWS re:Invent はいかがでしたか。 AWS re:Invent で見たいと思っていたセキュリティ、アイデンティティ、コンプライアンスのセッションを全部見ることができましたか? 見逃した場合でも心配しないでください。2020 年にリリースされたすべてのセッションは AWS re:Invent ウェブサイト経由でストリーミング配信されています。さらに、2021年には新しいセッションとして、1月12日から15日にライブストリーミングを行います。新しいセキュリティ、アイデンティティ、コンプライアンスセッションを以下にご紹介します ― 各セッションは複数回提供されますので、場所やスケジュールに合わせて最適な時間でご視聴下さい。   Protecting sensitive data with Amazon Macie and Amazon GuardDuty – SEC210( Amazon Macie と Amazon GuardDuty で機密データを保護する) Himanshu Verma, AWS Speaker 1月13日 水曜日 4:00 AM – 4:30 AM JST 1月13日 水曜日 12:00 PM – […]

Read More

ゼロトラストアーキテクチャ: AWS の視点

本投稿は、AWS の CISO オフィスのディレクターを務める Mark Ryland と AWS Identity の専門家である Quit Van Deman による寄稿を翻訳したものです。 アマゾン ウェブ サービス(AWS)の使命は、安全なシステムの構築、デプロイ、迅速な反復処理を行う際に行う作業がより少なくなるようにお客様に代わってイノベーションを行うことです。お客様からはセキュリティの観点について以下のような質問をよくいただきます、 “システムとデータの機密性、完全性、可用性を適切なレベルに確保し、スピードと俊敏性を向上させるのに最適なパターンは何ですか?“。ゼロトラスト・アーキテクチャまたはゼロトラスト・ネットワーキングのカテゴリーに該当するセキュリティアーキテクチャパターンが、これらの質問にどのように答えることができるか、お客様から具体的な質問を受ける機会が増えてきました。 このブログでは、ゼロトラストの名前を使用する技術への関心の高まりや、ゼロトラストに関する様々なコンセプトやモデルへの関心が高まっていることを踏まえ、私たちの視点をお伝えしたいと考えています。

Read More

re:Invent 2020 – アイデンティティとデータ保護関連セッションのご紹介

例年と異なり、今年の AWS re:Invent はラスベガスで皆さんとお会いするかわりに、3週間の無料のバーチャルカンファレンスになります。その一方変わらない事は、多くのセキュリティ、アイデンティティ、コンプライアンスのセッションを含む、様々なセッションが用意されていることです。私たちはセッションを準備するにあたり、お客様にどの知識を深めたいかを尋ねました。その一つの方法として、セキュリティブログの記事で以前紹介した、お客様から直接フィードバックできる新しい投票機能 を利用しました。今回の投票結果で、アイデンティティとアクセス管理、データ保護がお客様にとって最も興味のあるトピックであることがわかりました。そこでこのブログでは、2つのトピックに関する re:Invent のセッションを紹介いたします。re:Invent のスケジュールを立てる際にぜひ活用いただければと思います。各セッションは複数回開催されますので、お住まいの地域やスケジュールに合わせてお申し込みください。

Read More

Amazon Macie のカスタムデータ識別子を使用して機微情報を検出する方法

クラウド上により多くのデータを格納していくと、スケールする形でデータを安全に維持するためのセキュリティ自動化が必要になってきます。AWS は最近 Amazon Macie をリリースしました。これは機械学習とパターンマッチングを使って AWS クラウド上の格納データの中の機微情報を検出し、分類し、保護するためのマネージド・サービスになります。 多くのデータ侵害は、承認されていないユーザーの悪意を持った活動によるものではありません。それよりも、承認されている正規のユーザーのミスによるものが多いのです。機微なデータのセキュリティを監視して管理するには、まずデータの存在を特定する必要があります。このブログ記事では、Macie のカスタムデータ識別子をどのように使うかを紹介します。機微データの存在が分かると、次にスケールする形で、監視とリスクの自動低減を実行するためのセキュリティコントロールのデザインに着手出来ます。 Macie はいくつかのタイプの機微データを検出するためのマネージドデータ識別子を提供しています。この識別子は多くの組織で必要とされる一般的な要件に対応しています。Macie がユニークなのは、特定のデータ要件に対応していることです。Macie の新しいカスタムデータ識別子を利用することで機微データの検出を強化することが可能です。カスタムデータ識別子は組織特有のデータ、知的財産や特定のシナリオに対して使えます。 Macie のカスタムデータ識別子は組織特有の要件をベースとして機微データを見つけて特定します。このブログ記事では、自動的に特定の機微データを検出するためにどのようにカスタムデータ識別子を定義して実行するのかをステップバイステップで紹介していきます。カスタムデータ識別子の利用を開始する前に、Macie の詳細なロギングを有効化する必要があります。まだ、ご覧になられていない場合には、Macie の有効化手順についてはこちらの手順を、詳細なロギングについてはこちらの手順をご覧ください。 カスタムデータ識別子が必要なケース まず最初に、皆さんがフランスに本社がある製造業企業の IT 管理者であるという想定にしましょう。皆さんの会社はブラジルのサンパウロに研究開発拠点を持つ企業を買収しました。その企業は AWS にマイグレーションをしようとしています。そして、マイグレーションの工程の中で登録情報、従業員情報そして製品のデータを暗号化されたストレージと暗号化されていないストレージに格納します。 ここでは以下に示す3つのシナリオで機微データを検出する必要があると仮定します。 SIRET-NIC : SIRET-NICはフランスにおいて企業に振られる番号です。この番号は、National Institute of Statistics (INSEE) が企業が登録されたときに割り振るものです。下記の図が SIRET-NIC の情報を含むファイルのサンプルとなります。ファイルの中の各レコードは GUID、従業員名、従業員のE-mailアドレス、企業名、発行日付、SIRET-NIC 番号を含んでいます。 図1 : SIRET-NIC データセット Brazil CPF(Cadastro de Pessoas Físicas – Natural Persons Register) : CPF はブラジルの歳入省が国内で課税対象となっている人に割り振る固有の番号です。ブラジルオフィスに所属している従業員は全員CPFの番号を持っています。 プロトタイプに関する名前付けルール : 企業は、既にリリース済みの公開されている製品と、プロトタイピング中で機密扱いされている製品を持っています。下記の例は、ブラジルのCPF番号とプロトタイプ名を含むサンプルファイルです。 図2 […]

Read More

AWS Single Sign-On ユーザーサインインプロセスの変更と準備方法

セキュリティの向上とユーザーエクスペリエンスの強化、AWS Identity との将来の互換性のために、AWS Single Sign-On (SSO) はサインインプロセスの変更が予定されています。一部の AWS SSO のユーザーに影響を与えるこの変更は、2020 年 10 月上旬に実施される予定です。

Read More

AWS Well-Architected Framework のセキュリティの柱をアップデートしました

お客様からのフィードバックと新しいベストプラクティスに基づいて、AWS Well-Architected Framework のセキュリティの柱をアップデートしました。この記事では、セキュリティの柱のホワイトペーパーと AWS Well-Architected Tool の変更点の概要を紹介し、新しいベストプラクティスとガイダンスについて説明します。 AWS は、お客様がセキュアで高パフォーマンス、耐障害性、効率的なインフラストラクチャを構築することを支援するために、Well-Architected Framework を開発しました。Well-Architected Framework は、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化の5つの柱から成り立っており、お客様、パートナー、AWS 内の各チームからのフィードバックを受けて、定期的にフレームワークを更新しています。またホワイトペーパーに加えて、AWS Well-Architected Tool も用意されており、ベストプラクティスに照らし合わせてアーキテクチャをレビューすることもできます。

Read More

AWS セキュリティドキュメントに150 以上の AWS サービスが追加されました

2019 年 6 月の AWS セキュリティブログで説明した、 AWSドキュメント の取り組みについての最新情報をお伝えします。 AWS セキュリティドキュメントに 150 以上のAWS サービスが追加されたことをお知らせできることを嬉しく思います。 AWS セキュリティドキュメントに馴染みがない方のためにお伝えすると、これは既存のサービスドキュメントの中にあるセキュリティコンテンツを簡単に見つけることができるように開発されたもので、AWS サービスのセキュリティ機能を確認する際に複数のソースを参照する手間を省くものです。これは、AWS 責任共有モデルで説明されている、クラウド “の” セキュリティ、クラウド “における”セキュリティに関する情報を含む、AWS クラウド導入フレームワーク( Cloud Adoption Framework – CAF)のセキュリティに沿った内容となっています。各章では、各 AWS サービスに適用される CAF の中から、以下のセキュリティトピックを取り上げています。

Read More

クラウドサービスの評価を最適化する方法

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

Read More

AWS Shield の脅威ランドスケープレポートが利用可能になりました

AWS Shield は、アプリケーションの脆弱性、不正なボット、分散サービス妨害(DDoS)攻撃から AWS で実行されているアプリケーションを保護する、マネージド型脅威保護サービスです。AWS Shield の脅威ランドスケープレポート(TLR)は、AWS Shield によって検出された脅威の概要が説明されています。このレポートは、AWS のお客様に代わって保護を構築するために、脅威状況を継続的に監視、評価している AWS 脅威リサーチチーム(TRT)によって作成されたものです。これには、 AWS WAF の AWS マネージドルール や AWS Shield Advanced など、サービスのルールと緩和策が含まれています。この情報を使用して、外部の脅威に関する知識を広げ、AWS で実行されるアプリケーションのセキュリティを向上させることができます。 2020 年第 1 四半期を対象とする最新のレポートから、調査結果の一部をご紹介します。

Read More