Amazon Web Services ブログ

Tag: セキュリティ

AWS上でどのようにゼロトラストアーキテクチャを考えていくか

厳しい規制への対応やリスク回避を考慮事項として擁するお客様は、レガシーアプリケーションのリファクタリングや新しいアプリケーションのデプロイに際し、ゼロトラストアーキテクチャに関心を向けることがあります。このブログでは、お客様がお客様のアプリケーションを評価し、ゼロトラストの原則とAmazon Web Services (AWS)を利用して安全でスケーラブルなアーキテクチャを構築するための手助けを行います。 ゼロトラストとは? ゼロトラストセキュリティとは、アプリケーションのコンポーネントやマイクロサービスが互いに分離しており、どのコンポーネントやマイクロサービスも他のコンポーネントやマイクロサービスを信頼していないというモデルです。これは、あらゆるソースからの入力を潜在的に悪意のあるものとみなすように設計されたセキュリティの考え方です。基礎となる内部ネットワーク・ファブリックを信頼しないことから始まり、さらにすべてのマイクロサービスにおける入力と出力の評価におよびます。加えて、個々のコンポーネント、マイクロサービス、またはアイデンティティの侵害から保護するために、多層防御アプローチを設計することも含まれます。 (訳者注:ゼロトラストは特定の製品やソリューションを指すものではなく多層的なセキュリティ手法を踏まえた概念として、現在アメリカ国立技術標準研究所(NIST)においても、SP800-207(本blog執筆時点においてはドラフト)として定義化が進められています。) 伝統的なネットワークセキュリティの設計は、セキュリティの境界に依拠します。境界内のすべてのものは信頼され、境界外のものは信頼できないものとみなされます。ゼロトラストネットワークは、ビジネスデータや機密リソースへの意図しないアクセスのリスクを低減するために、リアルタイムですべてのアクションとリソースを評価します。 ゼロトラストの原則を用いたAWS上での設計 ゼロトラストアーキテクチャをよりよく理解するために、脅威モデリングにより、従来のアーキテクチャやクラウドネイティブアーキテクチャとを比較してみましょう。脅威モデリングは、ユーザーはすべての潜在的な攻撃の可能性を評価してリスクを定義し、管理策を決定するための試みです。脅威モデルの一つであるSTRIDEでは、以下のようなカテゴリの脅威を特定しています。 ユーザーIDのなりすまし(Spoofing) データの改ざん(Tempering) ソースの否認(Repudiation) 情報漏洩(Information Disclosure) サービスの拒否(Denial of Service) 特権の昇格(Elevation of Privilege) AWSのベストプラクティスアーキテクチャ AWSでは、AWS上でWell-Architectedなアプリケーションを設計するための基礎となるツールを提供しています。AWS Well-Architected Frameworkは、AWSのベストプラクティスとワークロードを比較し、安定的かつ効率的なシステムを構築するためのガイダンスを得るための戦略を紹介しています。Well-Architected Frameworkには、セキュリティを含む5つの明確な柱が含まれています。このフレームワークを基に、ゼロトラストをAWSアーキテクチャに適用した例としてWebアプリケーションを考えてみましょう。 図1: Webサイトホスティングの例 表現されているアーキテクチャは、セキュリティを考慮したWell architectedの一例です。システムは、以下のサービスを活用して一般的な攻撃ベクターから保護されています。 Elastic Load Balancing (ELB)/Application Load Balancer (ALB)による負荷分散により、複数のアベイラビリティゾーンとAmazon Elastic Compute Cloud (Amazon EC2) Auto Scalingグループに負荷を分散し、サービスの冗長化と疎結合を実現します。 AWSのSecurity Groupを利用した仮想ファイアウォールでは、インスタンスにセキュリティを移動させ、Webサーバとアプリケーションサーバの両方にステートフルなホストレベルのファイアウォールを提供します。 Amazon Route 53を利用したDNS(Domain Name System)はDNSサービスを提供し、ドメイン管理を簡素化します。 Amazon CloudFrontによるエッジキャッシングにより、顧客へのレイテンシが減少します。  AWS Web […]

Read More
SharedResponsibilityModel

責任共有モデルとは何か、を改めて考える

本Blogは、クラウドにおける新しい常識”new normal”を考えるBlogの第二弾です。(第一弾「クラウドにおける安全なデータの廃棄」はこちら) 今回は、クラウドの基本的な考え方である”責任共有モデル”をとりあげます。こちらのBlogをご覧の皆様の中には”何故、いまだに責任共有モデルなのか”という疑問を持つ方もいらっしゃるかもしれません。しかし、未だに本モデルの考え方や実際のビジネスへの適用方法は十分に理解されていないようにも見受けられます。今回は責任共有モデルとは何か?を振り返るとともに、いくつかの理解のポイントをお伝えします。 セキュリティ責任共有モデルとは? ”セキュリティとコンプライアンスはAWSとお客様の間で共有される責任です。この共有モデルは、AWSがホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素をAWSが運用、管理、および制御することから、お客様の運用上の負担を軽減するために役立ちます。お客様には、ゲストオペレーティングシステム (更新とセキュリティパッチを含む)、その他の関連アプリケーションソフトウェア、およびAWSが提供するセキュリティグループファイアウォールの設定に対する責任と管理を担っていただきます。使用するサービス、それらのサービスの IT 環境への統合、および適用される法律と規制によって責任が異なるため、お客様は選択したサービスを慎重に検討する必要があります。また、この責任共有モデルの性質によって柔軟性が得られ、お客様がデプロイを統制できます。以下の図に示すように、この責任の相違は通常クラウド ’の’ セキュリティ(Security ‘of’ the Cloud)、およびクラウド ’における’ セキュリティ(Security ‘in’ the cloud)と呼ばれます。” 責任共有モデルを踏まえたセキュリティ効率性の改善 責任共有モデルを適用するうえでのメリットを考えてみましょう。例えばお客様がPCI DSS等の認証の取得を考えた場合、全ての要件を自社で管理を行うことは非常に負荷が高く、コストもかかる作業となります。AWSはPCI DSSを含めた様々なコンプライアンスプログラムや第三者認証に取り組んでおり、お客様は自らの認証の範囲からデーターセンターの物理的な統制を除外することができます。お客様はAWS Artifactからリポートを入手することで、物理統制の評価が可能となります。この場合、認証の範囲を縮小することは審査だけでなく運用上の負荷においても大きな便益をお客様にもたらします。 同様にAWSのサービスを考えた場合、Amazon EC2インスタンスにサービスを構築する場合と、Amazon RDSなどのマネージドサービスやAWS Lambdaなどのサーバレスアーキテクチャを活用してサービスを構築した場合では、パッチの適用やバックアップ管理等、セキュリティに関連する負荷は大きく異なります。サービス自体やセキュリティ管理策に対する運用の経済性を考えた場合、AWSにセキュリティ管理を任せることで、お客様はその分の投資をサービスの改善やより重要なワークロードに振り分けることができることになります。つまり、組織がガバナンス上で何を重要とするかといった考え方に基づき、選択肢を持つことが可能となります。 AWSは”クラウド内のセキュリティに対する責任”を助けないのか。 上記のモデル図で考えた場合、責任の分界点として、”ユーザのセキュリティに対してAWSは何もしてくれないのか”という疑問をもたれるケースがあります。もちろん、そうではありません。AWSは様々な手段でお客様のセキュリティの実現を支援します。第一に、AWSは豊富なセキュリティサービスや機能、アップデートを提供しています。AWSにおける脆弱性の発見等はセキュリティ速報に公開され、お客様はRSSフィードで購読することが可能です。これらにより、お客様は自らのニーズにあったセキュリティの実装や対応を行うことができます。次に、開発者ガイドや各種ホワイトペーパーなどをもとにお客様のセキュリティに対して必要な情報を提供しています。また、単に設定方法を伝えるだけではなく、Well Architectedフレームワークは、クラウドの特性を活かしたサービスの原則を提供することで、お客様のセキュリティを支援する道具になります。 また、支援は機能やサービスだけではありません。AWSではSolution Architectによる技術支援やProfessional Servicesによる有償コンサルティングサービスの提供、Certification and Training teamによるトレーニングサービスの提供、AWS Supportによるお客様課題の支援や対応窓口の提供など、様々な形での組織的な支援を行っています。例えばAWS Supportではナレッジセンターとしてお客様からのお問い合わせの頻度の多い質問に対する回答を公開しています。 また、お客様がコンプライアンスに準拠した環境でサービスを設計、運用するためには、実際の構築や運用の担い手となるパートナー様の尽力が不可欠です。政府機関における「政府機関等の情報セキュリティ対策のための統一基準群」に対するリファレンスや金融業界における「FISC安全対策基準」へのリファレンス等は、AWSJの協力に基づきAPNパートナー様により開発、公開されており、システムインテグレーターや開発、運用事業者はこれらを活用することが出来ます。 このようにAWSは組織的、技術的に様々なアプローチでお客様のセキュリティをサポートする手段を提供しています。 多くの”責任共有モデル”は二階層ではない。 上記のモデル図は”AWS”と”お客様”の二階層で責任共有を表現しています。しかし、様々な場合において、二階層で責任共有モデルを考えることは現実的ではないことがあります。例えば、日本では多くの調達や開発、運用において、システムインテグレーターや開発、運用事業者が存在する場合がありますし、例えばお客様がSaaS事業者と契約した場合、そのインフラストラクチャをAWSが提供している場合があります。こうした場合、セキュリティは重層的になります。実際にはお客様の中でも様々な責任共有の形があります。また、お客様の中にも責任共有モデルは存在します。事業部門とシステム部門、監査やリスク管理部門など、単一の組織においてもセキュリティの責任は複数の組織で共有しているものとなります。責任の範囲を明確にすることは本来は自然なことであり、まずは範囲を明らかにした上で、どのように協働をおこなうかというプロセスが重要になります。 重層的な責任共有モデルにどう向き合うか お客様がSaaS事業者やシステムインテグレーターと契約した場合、セキュリティに対する説明責任はそのような事業者自身がAWSが提供する様々な情報を活用してお客様と向き合うとともにセキュリティの実装などに責任を持つことになります。こうしたパートナー様のエコシステムの育成や拡充のために、APNパートナープログラムではセキュリティコンピテンシーやパブリックセクターコンピテンシー等、お客様が業界や技術に明るいパートナーを選択できる仕組みを提供しています。既にご説明したAPNパートナー様によるセキュリティリファレンスなどの取り組みも進展しています。また、お客様の中における責任共有モデルにおいても、AWSでは実際にお客様の様々なクラウド移行を支援してきた経験から、お客様内におけるクラウド推進組織であるCloud Center of Excellence (CCoE)の設立などをベストプラクティスとしてお客様にお伝えしています。 責任共有モデルは”セキュリティだけ”のものではない。 このような責任共有という考え方は、”セキュリティだけ”に適用されるものではありません。例えば、ある情報システムのクラウド移行を想定した場合にも、“移行計画”の策定、“予算”の見積もりと確保、“クラウド要件”の定義、“調達/購買”の実施、(特に公共部門の場合には)“契約”の締結、実際の“精算”・・といった一連のプロセスが伴います。ここで注目すべきは、ユーザ側・調達者側が上記の一連のプロセスにおいてガバナンスを強化することが望ましい「new normal」においては、従来のモデルとは責任主体や責任の共有の仕方が異なるケースが頻発する、ということです。例えば:  “予算”の見積もりと確保──クラウドのコストメリットは、従量課金により実際に使った分だけを支払うことができる点に求められます。旧来の情報システムの発注は、その運用までも含め、固定額で見積もられることがほとんどでした。しかしクラウドを前提とした予算の確保では、ユーザ側・調達者側が積極的にクラウド利用料金の実績値管理(その頻度は週次であったり、日次で行うことも可能です)に主体性を持ち、次年度(場合によっては次期四半期)の予算確保の精度を継続的に上げていくことが求められます。ツールとしてはAWS Cost Explorer等が役立つはずです。 “調達/購買”の実施──旧来の情報システムの“調達/購買”においては、システム・インテグレーター(SI)によってシステム構成要件の全てを満たすことが期待されていました。しかしクラウドを前提とした調達/購買においては、これらの要件をSI/AWS/調達者の三者(あるいは、リセラーを含めた四者)によって分担し、共有することが必要となります。SIに求めるべきことをクラウドサービス事業者に求めるべきではなく、その逆もまた然りであるため、両者には別途独立した要件を求めることが妥当です。 […]

Read More

(開発中)AWS IoT Device Defender: IoTデバイス群を安全に

IoT においてスケールは新しい意味を持ちます。昨年、私は幸運にも平均1平方メートルごとに環境センサーがある巨大な工場を見学しました。そのセンサーは温度、湿度、空気純度を毎秒数回計測し、汚染物質に対する早期警戒を提供します。お客様からは何百万台、何千万台のコンシューマ向けIoTデバイスの展開に関心を持たれていると聞きました。 地理的に分散して展開されている強力で長寿命なデバイスのセキュリティ課題は重要です。しかし、限定的なCPUパワーやメモリしか無く、暗号化やその他のデータ保護手段の実施が制限される事があります。 このセキュリティ課題に対処し、自信を持って大規模にIoTデバイスを展開できるように、IoT Device Defender を開発中です。詳細はリリースまでに変更になる可能性がありますが、AWS IoT Device Defender は以下の利点を提供できるよう設計しています。 継続的な監査 – AWS IoT Device Defender はデバイスに関連するポリシーを監視して、指定された設定が行われているよう助けます。ベストプラクティスからの逸脱を探し、カスタムの監査ルールをサポートしているため、あなたのIoTデバイス展開に特有の状態をチェックすることができます。例えば、他のデバイスからセンサーデータを購読されているような侵害されたデバイスでは無いか確認することができます。監査はスケジュールにもとづいて実施したり、必要に応じて実施したりできます。 リアルタイム検知とアラーム – AWS IoT Device Defender は侵害されたデバイスが行うような通常とは異なる動作を見つけ出し、素早く警告を出します。類似したデバイスの動作を長期間モニタリングし、許可されていない試行アクセスや接続パターンの変化、インバウンド・アウトバウンド両方のトラフィックパターンの変化を探し出すことで実現します。 素早い調査と緩和 – 何か通常とは異なることが起こって警告を受取った際、AWS IoT Device Defender は警告についての状況を始め、問題の調査や緩和を行うのを手助けするツールを提供します。デバイスの情報、デバイスの統計情報、診断ログ、過去のアラートなどを全て簡単に確認できます。デバイスを再起動したり、権限を取り消したり、工場出荷時のデフォルトに戻したり、セキュリティパッチを送ったりなども選択できます。 乞うご期待 より詳細な情報やハンズオン記事を可能な限り早くお届けしたいと考えています。乞うご期待下さい。 — Jeff (翻訳は SA 辻 義一 が担当しました。原文はこちら)

Read More

政府統一基準に対応したAWSクラウド利用のセキュリティリファレンス提供の取り組み@パブリックセクターシンポジウム ~AWS Summit Tokyo 2017~

  政府統一基準に対応したAWSクラウド利用のセキュリティリファレンスについて   アクセンチュア株式会社、株式会社NTTデータ、PwCあらた有限責任監査法人、富士ソフト株式会社は共同で、内閣サイバーセキュリティセンター(NISC)制定の政府統一基準に対応したAWSクラウド利用のセキュリティリファレンスを作成し、2017年3月23日より無償提供を開始しました。本リファレンスは、2016年8月31日に改訂された「政府機関の情報セキュリティ対策のための統一基準(平成28年度版)」を背景としており、クラウドの選定および利用の際のガイドラインやセキュリティ要件等の基準が追加されたことに対して、AWSクラウド環境におけるセキュリティ対応策の詳細を網羅的に提示しています。 サイバーセキュリティ基本法に基づいてNISCが制定する政府統一基準(以下、NISC統一基準)は、国内の政府機関が実施すべきセキュリティ対策の指針として幅広く利用されています。一方で、その要件やチェック項目は複雑かつ広範にわたるため、AWSクラウド等のクラウドを利用する際に、そのガイドラインや要件を満たすことを確認することは容易ではありませんでした。このたび共同開発した本リファレンスは、各社の情報セキュリティ対策に関する知見と実績を結集したものです。政府統一基準への準拠のノウハウを具体的に提示することにより、各政府機関が安全で信頼性の高いシステムを実現することを支援できるものと期待しています。   パートナー各社の取り組み   2017年5月30日に開催された「パブリックセクタ― シンポジウム ~AWS Summit Tokyo 2017 – Dive Deep Day~」にて、本リファレンスの作成者であるパートナー各社によるパネルディスカッションが行われ、各社の取り組みが紹介されました。

Read More

ランサムウェア「WannaCry」に関するAWSへの影響について

  2017年5月12日頃からWannaCry(別名、WCry、WanaCrypt0r 2.0、Wanna Decryptorなど)と呼ばれるランサムウェア(身代金マルウェア)による被害が世界中から報告されはじめました。日本でも複数の大手企業がこのマルウェアに感染したというニュースが報道されています。 このマルウェアは、ファイル共有および印刷共有サービスを提供するWindows SMBサーバー上に存在する脆弱性を悪用します。デフォルトでは、SMBサーバーはUDPポート137/138およびTCPポート139/445で動作します。また、Windowsオペレーティングシステムの複数のバージョンが対象で、Microsoft社は、この脆弱性を解消するため、2017年3月14日にMicrosoft Windows SMB Server(4013389)の重要なセキュリティ更新プログラムをリリースしました。詳細は、Microsoft MSRC blog もしくは Microsoft Security Bulletin MS1​​7-010 をご参照ください。   WannaCryによるAWSサービスへの影響   EC2 Windows   Amazon EC2上のWindowsに関しては、AWSから提供されている2017.04.12以降のリリースのAMIであれば、この脆弱性の被害を受けていません。また、自動更新が有効になっている場合も、この脆弱性は解消されています。2017.04.12より前のAMIを使用している、かつ、自動更新を有効にしていないお客様は、前述のセキュリティ更新プログラムをインストールすることをお勧めします。 AWSでは、セキュリティのベストプラクティスに従い、セキュリティグループの設定を確認し、その必要のあるインスタンスおよびリモートホストに対してのみ前述のポートへのアクセスを許可することを、常にお勧めしています。デフォルトでは、EC2セキュリティグループはこれらのポートをブロックします。 AWSのWindows AMIのリリースノートはこちらです。   WorkSpaces   Amazon WorkSpacesに関しては、2017 年4月15日以降にWorkSpaceを作成した、または、自動更新を有効にしたAmazon WorkSpacesのお客様は、この脆弱性の影響を受けません。 2017年4月15日より前にWorkSpaceを作成し、自動更新を有効にしていないお客様は、セキュリティ更新プログラムをインストールするか、 WorkSpaceを終了して再作成することをお勧めします。   Directory Service   AWS Directory Serviceに関しては、2017/05/20時点でパッチ適用作業が完了しました。お客様による対応は必要ありません。Amazon Simple AD、 AD Connector、AWS Cloud Directory はこの問題の影響を受けていません。最新情報につきましては、下の原文へのリンク先をご参照ください。   Elastic Beanstalk   […]

Read More

サーバレス JavaScript アプリケーションで SAML: Part I

このブログ記事は AWS の Richard Threlkeld, Gene Ting, Stefano Buliani によって AWS Compute Blog に投稿された「SAML for Your Serverless JavaScript Application: Part I」の翻訳記事です。 このブログ記事に掲載したコードや SAM テンプレートの全体は samljs-serverless-sample GitHub レポジトリにあります。手動でリソースを作成する事もできますが、GitHub レポジトリにある SAM テンプレートを使ってリソースを作成することを強くお勧めします。 SAML 認証連携を実現したくありませんか? AWS プラットフォームで使うことができる一時的なセキュリティ認証情報の発行を、短期間の SAML アサーションを交換で実現できます。 エンタープライズ Web アプリケーションを構築する時は、認証や認可が一貫して行われ業界のベストプラクティスに沿っている事が必須事項です。AWS では、ユーザに一意のIDを作成し、AWS のサービスにアクセスできる短期間の認証情報を使えるようにできる Amazon Cognito と呼ぶサービスを構築しました。これらの認証情報は、IAM ポリシーに基づくロールと関連付けて、異なるリソースへのアクセスを許可や拒否する事ができます。 この記事では、Amazon Cognito で SAML プロバイダと認証連携を行う異なる方式を紹介していきます。応用すると、異なるタイプの認証プロバイダ (IdP) と連携させることができます。Facebook、Twitterやその他のサードパーティのソーシャルメディアを IdP にする事もできます。Amazon Cognito […]

Read More

AWS Artifactのご紹介:コンプライアンスレポートへの高速なアクセス

私はAWS Artifactを発表できることを嬉しく思います。AWSのお客様は、AWS マネジメントコンソールを使って、無償かつセルフサービスで、AWS コンプライアンスレポートへアクセスできるようになりました。 AWSの多くのお客様は、ISO、SOC、そしてPCIに関するAWSのコンプライアンスレポートを監査人や規制当局に提供しています。これには、AWSインフラストラクチャとサービスの現在および過去のコンプライアンスレポートが含まれます。 あなたは今、コンピュータまたはモバイルフォンからAWSマネジメントコンソールにサインインし、関連するレポートを数分で取得する事ができます。 また、監査人や規制当局にAWS Identity and Access Management (IAM) の権限を使用して、1つまたは複数のAWSコンプライアンスレポートへの直接アクセスをさせることができます。 AWSのリスクとコンプライアンス担当ディレクターのChad WoolfはArtifactのビジョンについてこう語ります。「AWSが提供するセキュリティを評価する観点において、顧客と監査人に選択肢と利便性を提供できることに私たちはうれしく思っています。」Woolfは言います。「AWS Artifactのリリースは、AWSが監査業界を変革するきっかけとなり、時間のかかるマニュアルの監査から、クラウドによる継続的で高度に自動化された環境へと移行します。」 あなたは今日から、AWS マネジメントコンソールから監査レポートのダウンロードを開始することができます。 多くの文書は機密情報であり、Amazonの機密保持契約条件に同意する必要がありますが、それらの条件を確認して同意すると、レビュー文書に即座にアクセスできます。Getting Started with AWS Artifactも参照してください。 Artifactの詳細については、Artifact home pageを参照してください。 AWS クラウドコンプライアンスと認定の詳細については、AWS Cloud Compliance home pageをご覧ください。 – Sara TAGS: AWS Artifact, Compliance reports (日本語訳はSA藤倉が担当しました。原文はIntroducing AWS Artifact: Speeding Access to Compliance Reports)  

Read More

新発表 – AWS Key Management ServiceでのBring Your Own Keys機能

AWS Key Management Service (KMS) は暗号鍵のシームレスな中央集中管理を提供します。私達のお客様は、鍵管理インフラストラクチャ(KMI)に関する、可用性、スケーラビリティ、物理的なセキュリティ、ハードウェアメンテナンスを自動的にハンドルするこのフルマネージドなサービスをとても気に入っています。また、KMSは、作成、ローテーション、ライフサイクル管理機能を持つ一つのダッシュボードで鍵管理を集中化します。初期費用無し、カスタマーマスターキー(CMK)1つ当たり月額$1の利用価格をベースとして、KMSは、S3, EBS, RDS, Redshift, およびその他のKMSとインテグレートされたAWSサービス内に保管されたデータを容易に暗号化することが出来ます。 多くのAWSのお客様は、鍵を作成して管理するのにKMSを利用しています。しかしながら、KMSが提供するその他の機能を活用しながら、鍵に対するローカルコントロールを維持したいというお客様がいらっしゃいます。お客様は私たちに、世代や鍵の保管場所に関するローカルコントロールは、よりセンシティブなワークロードをクラウドで稼働させるためのセキュリティとコンプライアンス要求を満たすのに役立つと仰っています。 Bring Your Own Keys  このような重要なユースケースをサポートするために、本日、KMSにユーザー独自の鍵を持ち込むことが可能になったことを発表できることを嬉しく思います。この機能により、極めてセンシティブなワークロードが保護でき、AWSの外に鍵のセキュアなコピーを保持することが可能になります。この新しい機能により、RSA PKCS #1標準をサポートする全ての鍵管理およびHSM(Hardware Security Module)ソリューションからの鍵のインポートが可能になり、その鍵をAWSサービスおよびアプリケーションから利用することが可能になります。また、KMSは詳細な監査情報を提供するためにAWS CloudTrailと協調して動きます。全てをまとめると、高可用性を提供するためにAWSを利用すれば、鍵のライフサイクルと耐久性に強大なコントロールを得ることができます。今日のほとんどの鍵管理ソリューションはHSMをバックエンドに使っていますが、全てのHSMが鍵管理ソリューションを提供するわけでは有りません。 インポートプロセスは、AWSマネージメントコンソールを使う,  AWS CLIを使う,  あるいは KMS APIをコールすることによって開始できます。オープンな環境に秘密鍵を転送させないために、インポートプロセスでは、アカウントにユニークな、KMSによって提供される公開鍵を使って、事前にユーザーのKMIの鍵をラップすることが求められます。鍵をラップするために、PKCS #1 スキームを利用することができます。 私は、Importing Key Material in AWS Key Management Serviceの指示に従って、KMSコンソールでCreate keyをクリックすることから始めます: エイリアスと説明を入力し、外部(External)を選択し、“I understand…”チェックボックスにチェックを付けました: それから、鍵管理のためのKMS APIを許可するIAMユーザーのセットを選びます。(このステップは、次に行うようにKMSおよび外部キーの両方に適用されます。): 次に、鍵を使ってデータの暗号化/復号化ができるIAMユーザーのセットを選択します: キーポリシーを確認し、ラッピングキーとインポートトークンをダウンロードしました。ラッピングキーは、私がKMSにインポートして使おうとしている256bitの秘密鍵を暗号化するのに利用する2048bitのRSA公開鍵です。インポートトークンは、私の鍵をKMSに正しくインポートさせるためのメタデータを含んでいます。 ZIPファイルを展開し、ラッピングキーを私のEC2インスタンス上のディレクトリ上に配置しました。それから、opensslコマンドを2度使いました:一度目は秘密鍵を生成するためで、2度目はその秘密鍵をラッピングキーでラップするためです。インポートする256bit鍵を生成するためにopensslを便利な方法で利用している事に注目してください。本番データ用としては、鍵の生成と保管にもっとセキュアな方法(商用の鍵管理やHSMソリューションが望ましい)を利用すべきです。 $ openssl rand -out plain_text_aes_key.bin 32 $ openssl rsautl -encrypt -in plain_text_aes_key.bin -oaep \ -inkey wrappingKey_fcb572d3-6680-449c-91ab-ac3a5c07dc09_0804104355 \ -pubin -keyform DER -out enc.aes.key 最後に、“I am ready to upload…”をチェックしてNextをクリックし、鍵の有効期限と共に鍵マテリアルを指定して、全ての情報が集まります。有効期限を過ぎた後はAWSから利用できなくなるので、要件がはっきりするまで有効期限無しのオプションを選択したいと考えるかもしれません。いつでも同じ鍵を再インポートして、有効期限を後からリセットすることができます。 Finishをクリックして、鍵が有効化され利用できるようになりました: […]

Read More

AWSが新しいPCI DSS 3.2を採用する最初のクラウドサービスプロバイダに

2016/2017サイクルのアマゾンウェブサービスPCI DSS 3.2 コンプライアンスパッケージがご利用可能になったことを発表できることを嬉しく思います。AWSは、新しくリリースされたPCI Data Security Standard(PCI DSS) version 3.2に対するアセスメントを成功裏に完了した最初のクラウドサービスプロバイダ(CSP)です。また、これは強制的なデッドラインである2018年2月1日の18ヶ月前に達成されました。リクエストによってご利用可能なAWS Attestation of Compliance (AOC)には、最も最近追加されたAmazon EC2 Container Service (ECS), AWS Config, および AWS WAF (ウェブアプリケーションファイやーウォール)を含む、26のPCI DSS認定サービスが掲載されています。AWSは、この国際的な情報セキュリティおよびコンプライアンスプログラムにコミットしています。新しい基準に対して可能な限り早く再び対応することは、情報セキュリティを最優先としてしているAWSのコミットメントを例証しています。AWSのお客様(およびそのお客様)は、最新かつ最も成熟したPCIコンプライアンス要求のセットに対してAWSのプロダクトとサービスがテストされていることを知りながら、クレジットカード情報(およびその他のセンシティブデータ)をクラウドの中で保管し、処理する運用を自信を持って行うことができます。   What’s new in PCI DSS 3.2? PCI Standards Councilは、利用可能な要件の最新セットとして、2016年4月に PCI DSS 3.2 を発表しました。PCI DSS バージョン3.2では、オンラインクレジットカードトランザクションにおける暗号化、アクセスコントロール、変更管理、アプリケーションセキュリティ、リスクマネージメントプログラムまわりの要求が修正され、明確化されました。PCI Security Standards CouncilのChief Technology OfficerであるTroy Leachによる具体的な変更には以下が含まれます: 変更管理プロセスが、(年次のアセスメントに代わって)継続的なモニタリング環境の実装の一部として必要とされる サービスプロバイダはクリティカルセキュリティコントロールシステムの障害について検知と報告が求められる ペネトレーションテストの要求が年次から6ヶ月に一度に増加 カードデータを扱うシステムへのコンソール外の管理者アクセスについて多要素認証が求められる サービスプロバイダは、職員がセキュリティポリシーと運用手順に従っているかを確認するための四半期ごとのレビューを行う必要がある コンプライアンスパッケージの用途 AWS PCI […]

Read More

【新機能】 暗号化された EBS スナップショットのクロスアカウントコピー

AWS は既に、 Amazon Elastic Block Store (EBS) ボリュームとスナップショットの暗号化をサポートし、AWS Key Management Service (KMS)によって暗号化キーの保管、管理が行うことができます。また、他の AWS アカウントへの EBS スナップショットのコピーをサポートし、スナップショットから新しいボリュームを作成することができます。本日、暗号化された EBS スナップショットをAWS リージョン間で移動できる柔軟性とともに、アカウント間でコピーする機能が追加されました。 このアナウンスは、3つの重要な AWS のベストプラクティスのもとに作られました。 定期的にEBS ボリュームのバックアップを取得する 環境(開発、テスト、ステージング、本番)毎にアカウントを作成し、複数アカウントを利用する バックアップを含めた、データ(保管時のデータ)の暗号化を行う 暗号化された EBS ボリュームとスナップショット では、実際にこの機能を利用してみたいと思います。まずは、振り返りの意味もこめて、IAM コンソールを使って、暗号化キーを作成します。   そして、暗号化キーを指定し(他のアカウントにコピーを行う場合、カスタムキーを利用する必要があります)、暗号化された EBS ボリュームを作成します。 続けて、暗号化された EBS スナップショットをボリュームから作成できます。   今ご覧いただいたように、私は既に長いボリュームIDとスナップショットID を私のAWS アカウントで有効にしています(こちらに関しての詳細は、They’re Here – Longer EBS and Storage Gateway Resource IDs Now Available をご確認ください)。 クロスアカウントコピー 今までご覧いただいたことに、何も新しいものはありませんでした。では、新しい部分に入っていきましょう!他のアカウントに暗号化された […]

Read More