Amazon Web Services ブログ

Category: Security, Identity, & Compliance

Amazon DocumentDB をご利用中のお客様は 2020 年 2 月 5 日までに TLS 認証を更新ください

  Amazon DocumentDB (MongoDB との互換性がある) をご利用のお客様の場合、AWS から TLS 認証のローテーションについてお知らせメールを受信されたことでしょう。Amazon DocumentDB インスタンスの TLS 認定は、Amazon DocumentDB の標準的なメンテナンスとセキュリティのベストプラクティスの一環として、2020 年 3 月 5 日に有効期限が切れます。TLS を使用してクラスターに接続するすべての Amazon DocumentDB のお客様は、有効期限後に接続を維持するために行わなければならない手順があります。このブログ記事では、今後の Amazon DocumentDB 認定の有効期限について詳述し、クラスターが影響を受けるかどうかを確認する方法を説明します。そしてクラスターへの接続を維持するために何をすべきかをお教えします。 現在の状況 Amazon DocumentDB CA およびサーバー認定は、標準メンテナンスおよびセキュリティのベストプラクティスの一部として更新されています。現在のサーバー認定は、2020 年 3 月 5 日に期限切れになります。 2020 年 2 月 5 日から、Amazon DocumentDB クラスターのサーバー認定の更新を開始します。両方の手順をできるだけ早く完了するか、遅くとも 2020 年 2 月 5 日までに完了することを強くお勧めします。2020 年 2 月 5 日までに両方の手順を完了できない場合、クライアントまたはアプリケーションは […]

Read More

クラウドにおける安全なデータの廃棄

クラウドにおける統制をお客様が考慮する場合、基本的な考え方は大きく異なるものではありません。ただし、クラウドならではの統制を考慮すべきケースがあることも事実です。その際には、従来のオンプレミスのやり方を無理にクラウドに当てはめようとしてもうまくは行きません。大事なことはその統制が何を目的としていたのかに立ち返り、その上で、New normal(新しい常識)にあった考え方や実装をすすめる必要性を理解し、実践することです。この投稿では、メディアやデータの廃棄を例として、セキュリティのNew normalを考えていきます。 メディア廃棄における環境の変化 データのライフサイクルに応じた情報資産の管理は多くのお客様の関心事項です。 オンプレミスの統制との変更という観点では、メディア廃棄時の統制は従来のオンプレミス環境とクラウド環境では異なります。オンプレミス環境の利用者はハードウェアの消磁や破砕などを実行することでデータの保全を実行してきました。また、メディア廃棄をサードーパーティに委託し、その廃棄証明の提出をもって“確実な廃棄の証跡”として管理しているケースもありました。 AWSの環境ではセキュリティ責任共有モデルに基づき、クラウドのインフラストラクチャの管理はAWSの統制となるため、お客様はその統制が実施されるていることを評価していく必要があります。お客様はAWSが管理するハードウェアデバイスに物理的にアクセスすることはできないため、従来であれば自組織、場合によってはサードパーティに委託していたメディアの廃棄を自組織の統制範囲として行うことはありません。また、仮想環境のストレージは物理的なハードウェアと異なり、特定の利用者が占有しているとは限らないため、廃棄時に利用者に紐付けた管理や通知を行うことは現実的ではありません。 AWSにおけるメディアの廃棄 AWS データセンターは、セキュリティを念頭に置いて設計されており、統制により具体的なセキュリティが実現されています。ユーザーデータの保存に使用されるメディアストレージデバイスは AWS によって「クリティカル」と分類され、そのライフサイクルを通じて非常に重要な要素として適切に取り扱われます。AWS では、デバイスの設置、修理、および破棄 (最終的に不要になった場合) の方法について厳格な基準が設けられています。ストレージデバイスが製品寿命に達した場合、NIST 800-88 に詳細が説明されている方法を使用してメディアを廃棄します。ユーザーデータを保存したメディアは、安全に停止するまで AWS の統制から除外されることはありません。AWSで扱われるメディアはワイプ処理もしくは消磁処理され、AWSのセキュアゾーンを離れる前に物理的に破壊されます。AWS の第三者レポートに文書化されているように、AWS データセンターに対する第三者の検証によって、AWS がセキュリティ認証取得に必要となるルールを確立するためのセキュリティ対策を適切に実装していることが保証されます。お客様はこうした第三者のレポートをAWS Artifactから入手することが可能です。 AWSにおけるサードパーティの管理 AWSにおいては、本投稿執筆時点(2019年12月19日)においてお客様のコンテンツにアクセス可能なサードパーティーのプロバイダはありません。こうした事実は第三者の検証において評価を得るとともに、AWSのサードパーティアクセスページにおいて公表しており、また、変更がある場合にお客様は通知を受けることも可能です。 目的に立ち返る:なんのために”メディア廃棄”を行うか そもそもメディア廃棄の統制を行う目的は何でしょうか。脅威を踏まえて考えれば、組織の所有する(およびしていた)データが許可なく第三者に漏洩することを防ぐことにあります。メディア廃棄の証明をとることは、メディアの廃棄後も、データが第三者により許可なくアクセスされないことを評価するための手段にほかなりません。お客様にとって重要なことはデータがライフサイクルを通じて確実に保護されることです。メディアの廃棄の証明はその手段のうちの一つ(適切に処理されたことの保証手段)にすぎません。お客様の統制を離れたデータが保護されることを確実にすることに焦点をあてることで、環境がクラウドに変わったとしてもお客様の求める管理目的を達成することが出来るのです。 暗号化を活用したデータの保護と廃棄記録 AWSはお客様に重要なデータやトラフィックの暗号化による保護を推奨しており、そのための機能を提供しています。利用終了後もデータを保護する有効な手段として、暗号化による予防的な統制、そして処理の実行を確実に記録することは強く推奨されます。 暗号化がなぜ有効なのでしょうか。暗号化されたデータはそれを復号するための鍵がなければデータとして復元することが出来ません。暗号化に利用する鍵と暗号化されたデータへのアクセスを分離することで権限のない第三者によるデータへのアクセスを予防することが出来ます。このように暗号化を行い、その鍵を消去することはCryptographic Erase(CE:暗号化消去)としてNIST SP800-88においても紹介されています。 AWSのストレージサービスでは利用開始時にデフォルトで暗号化を行う機能を提供(Amazon EBS, Amazon S3)しています。また、Amazon Key Management Services (KMS)によりお客様の鍵によりデータを暗号化することが可能です。これによりお客様が定義したポリシーで鍵へのアクセスを統制しながら利用状況の証跡を取得することが可能となります。また、AWS Configにより意図しない設定の変更や設定ミスの検知および修正を自動化するといった発見的および是正的な統制を組み込むことも容易です。こうした統制を実施することでAWS上のお客様のデータに対して、ライフサイクルに応じた保護を行うことがより容易になりました。 お客様によるデータ廃棄の統制例 統制の一例として、ストレージ領域をデフォルトで暗号化を行う設定とすることで第三者によるアクセスへの保護を実現します。そしてEBSやS3 Bucketを削除する際には、あわせて当該領域の暗号化に用いた鍵をAWS Lambdaを使用してKMSより削除します。これにより従来行っていた当該データの復号が困難になるとともに廃棄証明の代わりとして、暗号化による保護を実施した記録をお客様自身で自動的に取得、管理することができるようになります。鍵へのアクセスが無くなることで、当然AWSによっても、またお客様も廃棄されたデータへのアクセスはできなくなります。   情報セキュリティを管理するためには目的にあわせた管理策を実施する必要があります。しかし一方で、手段自体が目的化してしまい、それを無理に新しい環境であるクラウドにあてはめてしまうアンチパータンが発生することがあります。本投稿ではメディアの廃棄を一つの例示としてとりあげましたが、セキュリティの管理策を実施するうえでの目的に立ち返り、クラウド上で行う上での妥当性、効果や効率性、そして何よりもクラウドの特性を生かしたさらなるセキュリティの向上を実現することでNew Normalに前向きに取り組むことができます。   このブログの著者 松本 照吾(Matsumoto, Shogo) セキュリティ アシュアランス本部 本部長 […]

Read More

EC2 インスタンスメタデータサービスの拡張により、オープンなファイアウォール、リバースプロキシ、SSRFの脆弱性に対する防御を強化しました

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

Read More

AWS 環境でセキュリティレスポンスの自動化を始める方法

AWS では、AWS 環境内のセキュリティイベントについて自動化による迅速な検知と対応をすることをお勧めしてます。自動化は、検知と対応の速度を向上させることに加えて、AWS で実行するワークロードを拡大するときにセキュリティ運用もスケーリングするのに役立ちます。これらの理由から、セキュリティの自動化は、Well-Architected フレームワークとクラウド導入フレームワークの両方、およびAWS セキュリティインシデント対応ガイドで概説されている重要な原則です。 このブログでは、AWS 環境内に自動セキュリティレスポンスメカニズムを実装する方法を学習します。このブログには、一般的なパターン、実装に関する考慮事項、およびソリューション例が含まれます。セキュリティレスポンスの自動化は、多くの分野にまたがる広範なトピックです。このブログの目標は、基本的な考え方を紹介し、セキュリティレスポンスの自動化の開始を支援することです。

Read More

AWS Identity and Access Management (IAM) Access Analyzer を使った意図しないリソースアクセスの特定

本日の発表をここでシェアしたいと思います。この発表は、AWS 上のビルダーの方のためのセキュリティ強化のみに留まりません。また、設定なしに利用料金不要でオンにすることが出来ます。AWS は、AWS Identity and Access Management (IAM) Access Analyzer と呼ばれる今までにない機能をリリースします。 IAM Acess Analyzer は数学的なアルゴリズムを使って AWS 上のリソースにアタッチされている アクセス制御ポリシーを分析し、他のアカウントもしくは、誰もがアクセスできるリソースが無いか見つけ出します。IAM Access Analyzer は継続的にAmazon Simple Storage Service (S3) バケット、IAM ロール、 AWS Key Management Service (KMS) キー、AWS Lambda 関数、 Amazon Simple Queue Service (SQS) キューといったリソースのポリシーを監視します。 IAM Access Analyzer によって、アクセス制御状況のインパクトを集約、可視化し、 利用されているアカウントの外側からの意図しないアクセスからリソースが保護されていることを確認出来ます。 いくつかの例をご紹介します。 IAM Access Analyzer の結果は my-bucket-1 という S3 バケットが ID 123456789012 の AWS […]

Read More

AWS KMS の新機能 公開鍵暗号によるデジタル署名

AWS Key Management Service で公開鍵暗号をサポートするようになりました。AWS SDK の新しい API を使ってアプリケーションデータを保護するために公開鍵、秘密鍵のキーペアを作成、管理、利用することが可能になりました。既に提供されている共通鍵暗号機能と同様に、公開鍵暗号の秘密鍵は KMS サービスの外側には出ないカスタマーマスターキー(CMK)として生成出来ます。また、データキーとしても生成可能で、データキーの秘密鍵の部分はアプリケーションに CMK で暗号化して渡すことが可能です。公開鍵 CMK の秘密鍵の部分は、AWS KMS のハードウェアセキュリティモジュールに格納されるため、AWS 従業員を含む誰も平文のキーマテリアルにアクセスすることは出来ません。AWS KMS のサポートする公開鍵のタイプは、 RSA 2048, RSA 3072, RSA 4096, ECC NIST P-256, ECC NIST P-384, ECC NIST-521, ECC SECG P256k1となります。 リリースの背景 システム間でデジタルメッセージの整合性を保証する一般的な方法はデジタル署名です。送信者は元のメッセージに暗号アルゴリズムに基づいた暗号鍵を使ってデータ構造を追加します。これにより、暗号鍵にアクセス出来る受信者は暗号学的にメッセージが改変されていないことを確認できます。受信者が送信者が使ったのと同じ暗号鍵にアクセス出来ない場合に、公開鍵暗号によるデジタル署名の仕組みが役立ちます。送信者は鍵の公開部分をすべての受信者に公開できますが、送信者は鍵の秘密部分を使って署名をコントロールすることが引き続き可能です。公開鍵暗号は信頼されたソースコードや認証認可用のトークン、文書の電子署名、エレクトリックコマースのトランザクション、セキュアメッセージングなどに利用されています。AWS KMS は 基本的なデジタル署名と言われている機能をサポートします。これは署名オブジェクトの中に ID 情報が含まれていないものです。一般的に ID 情報をデジタル署名に添付する方式はデジタル証明書です。もしお客様のアプリケーションが署名や署名確認のためにデジタル証明書を必要としている場合には、AWS Certificate Manager のプライベート CA 機能をおすすめします。 このサービスはデジタル署名アプリケーションのためにプログラム的に暗号鍵を含んだ証明書を作成してデプロイする機能を提供します。典型的なデジタル証明書を使うアプリケーションは、Webサーバー上で通信をセキュアにするために使われるTLS 処理です。 AWS KMS […]

Read More

AWS WAF 用 AWS Managed Rules の発表

 セキュアなアプリケーションの構築とデプロイは非常に重要な作業で、対象となる脅威も常に変化しています。当社では、クラウド上で強力なセキュリティ体勢を維持する苦労を低減するために、改善作業を継続的に行っています。本日、当社は新な機能として AWS Managed Rules for AWS WAF を公開しました。これにより、ルールを直接作成したり管理する必要がなく、アプリケーションの保護ができます。また、AWS WAF に対する複数の改善も行いました。向上した新しいコンソールと API によって、これまでなかったほど簡単にアプリケーションの安全維持ができます。 AWS WAF は、ウェブアプリケーションのファイヤーウォールです。これを使うと、アプリケーションに向けられたトラフィックの内、どれに許可を与えどれを拒否するかを制御するためのルールを定義できます。AWS WAF は、たとえば SQL インジェクションとかクロスサイトのスクリプトによる攻撃など、一般的な脅威をブロックするのに役立ちます。AWS WAFは、Amazon API Gateway、Amazon CloudFront、Application Load Balancer と合わせて使用することができます。本日は、多くのエキサイティングな改善点を公開していきます。今回発表した OR 演算子により、以前は複数のルールが必要であった評価が行えるようになるので、従来のルール作成にあった複雑さが低減されます。API の使いやすさも大いに改善されており、複雑なルールも 1 度の API 呼び出しだけで作成や更新が行えます。WAF Capacity Unit (WCU) が加わったことで、ウェブの各アクセスコントロールリスト (ACL) でルールは 10 個までという制限を撤廃しています。WCU に切り替えれば、数百のルールを作成できるようになります。ウェブのアクセスコントロールリスト (ACL) に追加された各ルールは、デプロイされているタイプに基づいた容量を消費します。そして、各ウェブ ACL には WCU の制限が定義されています。 新しい AWS WAF を使用する ここで、変更点のいくつかを確認しながら、AWS Managed […]

Read More

自分自身の暗号化キーを Amazon DynamoDB に利用

今日、Amazon DynamoDB は DynamoDB データの暗号化のための カスタマー管理型カスタマーマスターキー (CMKs) のサポートを導入しました。 しばしば bring your own encryption (BYOE) あるいは bring your own key (BYOK) と呼ばれるこの機能により、 DynamoDB で暗号化キーを作成、所有、管理することができ、自分の暗号化を完全にコントロールし、また、DynamoDB データの管理を行うことができます。 DynamoDB は完全管理されたマルチリージョン、マルチマスターデータベースで、保管時の自分のデータをデフォルトで暗号化し、DynamoDB データのセキュリティを強化します。以前には、DynamoDB はデータの暗号化のために AWS owned CMK あるいは AWS managed CMKを使用するオプションを提供していました。現在、カスタマー管理型 CMK を使用し、重要なアプリを保護し、自分の組織の方針を守り、コンプライアンスと規制上の要件を遵守し、AWS 外の自分の暗号化キーの追加の安全なコピーを保持できます。 このブログでは、保管時 DynamoDB 暗号化を用いたカスタマー管理型 CMK の使用法をお示しします。 DynamoDB 暗号化キーオプション AWS 管理 CMK を使用してデータを暗号化することを選択したのでなければ、DynamoDB は AWS 所有 CMK を使用して保管時テーブルデータの全てを正式に暗号化していました。しかし、現在、カスタマー管理型 CMK を使用することにより自分のデータを暗号化する選択肢があります。 […]

Read More

新しい ID フェデレーション – AWS でアクセスコントロールに従業員属性を使用する

AWS または他の多くのシステムのリソースへのアクセスを管理する場合、ほとんどの場合、ロールベースのアクセスコントロール (RBAC) を使用するでしょう。RBAC を使用する場合、リソースへのアクセス許可の定義、こうしたアクセス許可のポリシーによるグループ化、ポリシーのロールへの割り当て、個人、個人のグループ、サーバー、アプリケーションなどのエンティティへのロールの割り当てを行うことになります。多くの AWS のお客様は、組織内で同様のビジネス機能を共有している人などの関連するエンティティへのアクセス許可の付与を簡素化するためにそうしていると語っています。 たとえば、財務データベース管理者のロールを作成し、そのロールに財務に必要なテーブルやコンピューティングリソースへのアクセス権を付与することができます。データベース管理者の Alice がその部門に移動すると、彼女に財務データベース管理者のロールを割り当てます。 AWS では、AWS Identity and Access Management (IAM) のアクセス許可ポリシーおよび IAM ロールを使用して、RBAC 戦略を実装します。 リソースの増加により、スケーリングが困難になります。新しいリソースがシステムに追加されると、システム管理者は、その新しいリソースに対するアクセス許可をすべての関連するポリシーに追加する必要があります。何千ものリソースや数千のポリシーがある場合、これをどのように拡張すればよいでしょうか? 1 つのポリシーの変更がユーザーまたはアプリケーションに不要な特権を付与しないことをどのように確認すればよいでしょうか? 属性ベースのアクセスコントロール リソースが増え続ける状況の中、アクセス許可の管理を簡素化する新しいパラダイムが登場しました。属性ベースのアクセスコントロール (ABAC) です。ABAC を使用する場合、一致する属性に基づいてアクセス許可を定義します。ポリシーでは、ユーザー属性、リソース属性、環境属性など、あらゆるタイプの属性を使用できます。ポリシーは IF … THEN ルールになります。たとえば、 IF ユーザー属性 role == manager THEN 彼女は属性 sensitivity == confidential であるファイルリソースにアクセスできます。 ABAC アクセス許可コントロールを使用すると、リソースを追加するときにポリシーを更新する必要がなくなるため、アクセス許可システムの拡張が簡単になります。代わりに、リソースに適切な属性がアタッチされていることを保証する必要があります。ABAC では、ジョブロールごとにポリシーを作成する必要がないため、管理するポリシーの数を減らすことができます。 AWS では、属性はタグと呼ばれます。タグは Amazon Elastic Compute Cloud (EC2) インスタンス、Amazon […]

Read More

【開催報告】ビルシリーズ@住友不動産六本木グランドタワー 第1回

みなさんこんにちは!アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉です。 11月21日に「ビルシリーズ@六本木一丁目住友不動産六本木グランドタワー 第1回」を開催いたしました。今回は「初めてのサーバレスWebアプリケーションハンズオン」を実施しました。こちら「ビルシリーズとは?」とお思いの方も多いかと思いますので、開催報告と合わせてご説明いたします。 「ビルシリーズ」とは? このイベントは、日頃AWSをご利用いただいているお客様に、AWSからの情報発信はもちろん、同じビルに拠点を構えるお客様同士の活発な意見交換と交流の場を定期的に作ることを目的としたものです(同じビルなので移動が楽!)。 今回、住友不動産六本木グランドタワーのFringe81様、BASE様、エブリー様、ディップ様で同じようなニーズがあり、このようなビル単位でのイベントを開催する運びとなりました。場所はFringe81様の素敵な大会場をお借りいたしました。Fringe81様ありがとうございました。 来月には住友不動産麻布十番ビルでも開催を予定しており、今後もこのようなビル単位で交流ができるようなイベントを開催していきたいと考えております。 当日の様子 当日は約40人のお客様にお越しいただき、イベントは終始盛り上がりを見せておりました。   まずはAWSJ 植本より、今回のビルシリーズの趣旨などを説明いたしました。   次に、AWSJ 木村より「サーバレスのご紹介 – ユースケースパターンを切り口に」というタイトルで、AWSのサーバレスプラットフォームについてご紹介いたしました。   続けてAWSJ 木村より「初めてのWebアプリケーションハンズオン」を実施いたしました。   ハンズオンの終了後、ご参加いただいた皆様と共に、簡単な懇親会を開催いたしました。   今回、AWSJより、アカウントマネージャー植本、藤田、細木、ソリューションアーキテクト上原、石見、小宮、木村がビルシリーズをサポートいたしました。こちらはソリューションアーキテクトの集合写真です。 貴社担当のアカウントマネージャから「ビルシリーズ」のお誘いがあるかもしれませんが、是非ご検討いただければと思います。それでは、次回のビルシリーズでお会いしましょう!   著者について 木村 公哉(Kimura, Koya) 香川県出身のソリューションアーキテクトです。好きなサービスはAWS AmplifyとAWS Lambda、Amazon Kinesisです。好きな食べ物はうどんです。   上原 誠(Uehara, Makoto) アマゾンウェブサービスジャパン株式会社のソリューションアーキテクトとして、主にメディア系のお客様に対する技術支援を担当。技術的な得意/興味領域としては、アナリティクス系テクノロジー、広告系ソリューションなど。

Read More