Category: Security, Identity, & Compliance

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 の熱気をお感じください！

先日 (2019/7/23) 開催しました AWS Black Belt Online Seminar「AWS CloudHSM」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。   20190723 AWS Black Belt Online Seminar AWS CloudHSM   AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます）   Q. SDKとCloudHSMは、直接接続は出来ないのでしょうか？ A. CloudHSMの暗号化や復号機能を利用する場合、CloudHSMクライアント経由である必要があります。 https://docs.aws.amazon.com/ja_jp/cloudhsm/latest/userguide/client-tools-and-libraries.html#client PKCS #11や、JCE、Webサーバー用のOpenSSL Dynamic Engine, Microsoft KSPおよびCNGプロバイダーでは、AWS CloudHSMソフトウェアライブラリーを利用しますが、これらのライブラリもCloudHSMクライアント経由でCloudHSMの機能を利用します。 CloudHSMクラスターとHSMの作成、修正、削除などのオペレーションを行うための、AWS CloudHSM APIについてはSDKからご利用が可能です。 Q. Classic から V2への移行に関して、気をつけておくべきことはございますか。資料情報があれば教えていただければと思います。 A. 英語のドキュメントになりますが、こちらのマイグレーションガイドがあるのでご確認ください。 大きな点としては、V2ではリージョンをまたがったクラスターがサポートされない点です。ClassicでリージョンをまたがったHAグループを設定していた場合には、CloudHSMのバックアップを別リージョンに転送して手動でCloudHSMクラスターを再構成する運用手順を確立しておく必要があります。 また、別の観点になりますが、ClassicとV2ではクラスターやHSMの構成情報なども異なるので、マイグレーション先のCloudHSMで新規にクラスターやHSMの定義をすることになることにご留意ください。 Q. CloudHSMは、Amazonのハードウェアがデータセンターに配置されているのですか？どこかのHSM製品なのでしょうか？ A. はい。AWSのデータセンター内にHSMハードウェアが設置されています。現在使用しているHSMハードウェアについては、FIPSのセキュリティプロファイルページに記載があります。 Q. 手動でのバックアップは出来ないのでしょうか？例えば鍵を作成した際等。 A. 任意のタイミングでの手動でのバックアップ作成は出来ません。定期的なバックアップ以外にバックアップが実行されるのは、クラスターを初期化したとき、クラスターにHSMを追加したとき、クラスターからHSMを削除したときとなります。ワークアラウンドとして、一時的にHSMの追加と削除を行い、バックアップを取得するということが考えられます。 […]

英国で EU 離脱（Brexit）のニュースがトップ記事となっていますが、先日、ロンドンでもう 1 つ重要なできごとがありました。Richard W. Downing 米国 司法副長官補佐が、Academy of European Law Conference において「海外のデータの合法的使用を明確化する法律」(Clarifying Lawful Overseas Use of Data Act) (通称「“CLOUD 法”」) についての誤解と真実に関してスピーチを行い、その後、米国司法省 (DOJ) から CLOUD 法の目的と範囲を明確にし、多くの誤解に対処するためのホワイトペーパーと FAQ が発表されました。このスピーチと DOJ のホワイトペーパーおよび FAQ をぜひお読みいただき、CLOUD 法の実態をご理解ください。簡単に言うと、CLOUD 法とは、国際的な犯罪やテロ活動に法執行機関が対処することを唯一の目的とした古い法律に、軽微な変更を加えたものです。CLOUD 法によって米国の法執行機関にクラウド内のデータに対して自由なアクセス権をが与えられる、という噂は事実ではありません。 DOJ のスピーチとガイダンスは正しい方向に進むための足掛かりにはなりますが、それだけでは不十分です。クラウドコンピューティング利用者がデータのアクセスに関する重要な問題を理解できるようにするために、各国の政府が行うべきことはたくさんあります。今日は、CLOUD 法に伴いクラウドサービスの利用方法を変える必要はないということをお客様に理解していただけるように、この法律に対する主な誤解について説明しようと思います。 過去 30 年にわたる法執行機関のデータアクセス権 1986 年に、「保管された通信に関する法律」 (Stored Communications Act (SCA)) が議会で制定され、電子的コミュニケーションに対する法執行機関のアクセスについて対応が行われました。制定当時は SCA が将来を見据えた法律だと思われていましたが、その後に新しいインターネットアプリケーションやクラウドコンピューティングなどの技術が出てくると、その対応は困難で何年もかかってしまいました。そこでの議論の 1 つは、米国外にあるデータを米国の法執行機関が取得することができるかどうかということでしたが、この議論は CLOUD 法の成立によって決着しました。米国でビジネスを行っている事業体 […]

この記事は、AWS SAP Global Specialty Practiceでシニアコンサルタントを務めるPatrick Leungによるものです。 SAP Global Specialty PracticeにおけるAmazon Web Services (AWS)のプロフェッショナルサービスの一環で、AWS上でのSAPの設計と展開に関してお客様を支援することがよくあります。SAPのお客様は、Amazon Elastic File System (Amazon EFS)やAWS Backupなどのフルマネージド型のAWSサービスを利用して、インフラストラクチャの運用やその他の付加価値を生まない無駄な作業からチームの負担を軽減することができます。 本ブログ記事では、AWS Single Sign-On (AWS SSO)を使用して、SAPユーザーが毎回ログインとログアウトすることなくSAP Fiori launchpadにアクセスできるようにする方法を紹介します。このアプローチにより、SAPユーザーにとって望ましいユーザー体験を提供し、エンタープライズセキュリティの完全性が確保されます。数回クリックするだけで、初期投資や独自のSSOインフラストラクチャを運用するための継続的なメンテナンスコストをかけずに、可用性の高いAWS SSOサービスを有効にできます。そのうえ、AWS SSOを有効にするために追加費用はかかりません。

【日本語訳】日本時間 2019年06月25日10:00 最終更新: 2019/06/18 11:45 PM PDT CVE 識別子: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479 Amazon Elastic Container Service (ECS) 2019年6月17,18日にパッチがあてられた Amazon Linux および Amazon Linux 2 のカーネルで更新版の ECS 最適化 Amazon Machine Image (AMI) が提供されました。最新バージョンの入手方法を含む ECS 最適化 AMI に関する詳細は https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html をご覧ください。 Amazon GameLift Linux ベースの Amazon GameLift インスタンス向けの更新版の AMI が、全リージョンで利用可能です。Linux ベースの Amazon GameLift インスタンスを使用しているお客様は更新版の AMI で新規フリートを作成されることをお勧めします。フリートの作成に関する詳細は https://docs.aws.amazon.com/gamelift/latest/developerguide/fleets-creating.html をご覧ください。 […]

本投稿は AWS コンテナサービスのプリンシパルディベロッパーアドボケートである Massimo Re Ferreによる寄稿です クラウドのセキュリティはAWSの最優先事項であり、コンテナチームの取り組みがその証でもあります。およそ1か月前、私たちは AWS Secrets Manager や AWS Systems Manager パラメータストアと、AWS Fargate タスクの統合機能を発表しました。 これにより Fargate のお客様は、ご自身のタスク定義から秘密情報を安全に、パラメータを透過的に利用することができます。 この記事では、秘密情報を確実に保護しつつ Secrets Manager と Fargate の統合を利用する方法の例を紹介します。 概要 AWS は複数の重要なセキュリティ上の基準を以って Fargate を高度にセキュアに設計しました。その 1つは、各Fargate タスクはそれぞれに分離境界があり、下層のカーネル、CPUリソース、メモリリソース、またはElastic Network Interface（ENI）を他のタスクと共有していないところです。 セキュリティに重点を置くもう 1 つの領域は、Amazon VPC ネットワーキング統合です。これにより、ネットワーキングの観点から Amazon EC2 インスタンスを保護する手法で Fargate タスクを保護できます。 この発表は、責任共有モデルの観点でも重要です。例えば、AWSのプラットフォーム上でソリューションを構築して実行するようなDevOpsチームは、アプリケーションコードの実行時に秘密情報、パスワード、機密パラメータをセキュアに管理する適切な仕組みや機能を必要とします。そして、プラットフォームの機能によって彼ら/彼女らがまさにそのようなことを可能な限り簡単に実行できるようにすることが私たちの役割なのです。 私たちは、時に一部のユーザーがセキュリティ面をトレードオフとして俊敏性を得るために、ソースコードに AWS 認証情報を埋め込んだままパブリックリポジトリにプッシュしたり、プライベートに格納された設定ファイルに平文でパスワードを埋め込んでいるのを見てきました。私たちは、さまざまなAWSサービスを利用している開発者が IAM ロールを Fargate タスクに割り当てることができるようし、AWS 認証情報を透過的に取り扱えるようにすることで、この課題を解決しました。 これはネイティブな […]

私は開発者です。少なくとも、管理者であることは受け入れているつもりです。確かに私は情報セキュリティの専門家ではありません。私の書き込みや設定が原因でセキュリティ上の問題が発生したため、これまでに 1 回以上呼び出されたことがあります。実験のためにシステムがデプロイを頻繁に行えるようにして、ゲートキーパーを取り除くときに、時々準拠していないリソースがこっそり侵入しようとします。こういった理由から、私は AWS Security Hub のようなツールが好きです。AWS Security Hub は、コンプライアンスチェックを自動化し、さまざまなサービスから総合的な洞察を得られるサービスです。このようなガードレールが確実に軌道に乗るように設置すれば、もっと自信を持って実験できるようになります。そして、複数のシステムからのコンプライアンス検出結果を 1 か所にまとめて表示することで、情報セキュリティでのセルフサービスがより快適だということがわかります。 クラウドコンピューティングで、コンプライアンスとセキュリティに関して責任を共有するモデルがあります。AWS はクラウドのセキュリティを管理します。データセンターのセキュリティから仮想化レイヤーおよびホストオペレーティングシステムに至るまで、すべてが管理対象になります。お客様はクラウド内のセキュリティを管理します。ゲストオペレーティングシステム、システム設定、および安全なソフトウェア開発方法について取り扱います。 現在、AWS Security Hub はプレビューされていません。一般的な用途では使用できるため、クラウド内のセキュリティ状態を理解するのに役立ちます。これは AWS アカウント間で機能し、多くの AWS サービスおよびサードパーティー製品と統合します。また、Security Hub API を使用して独自の統合を作成することもできます。 はじめに AWS Security Hub を有効にすると、IAM サービスリンクロールを介してアクセス許可が自動的に作成されます。自動化された継続的なコンプライアンスチェックがすぐに始まります。コンプライアンス標準はこれらのコンプライアンスチェックとルールを決定します。利用可能な最初のコンプライアンス標準は、インターネットセキュリティセンター (CIS) AWS Foundations Benchmark です。今年はさらに標準を追加する予定です。 これらのコンプライアンスチェックの結果は、検出結果と呼びます。それぞれの検出結果から、問題の重要度、報告されたシステム、影響を受けたリソース、その他の役立つメタデータを把握できます。たとえば、root アカウントに対して多要素認証を有効にしなければならないこと、90 日間使用されていない資格情報が無効になっていることがわかります。 集計ステートメントとフィルターを使用して、検出結果を洞察に分類できます。 統合 コンプライアンス標準の検出結果に加えて、AWS Security Hub はさまざまなサービスからデータを集計して正規化します。これは、、AWS Guard Duty、Amazon Inspector、Amazon Macie、および 30 の AWS パートナーセキュリティソリューションによる検出結果の中央リソースです。 AWS Security […]

米国国立標準技術研究所 (NIST) のサイバーセキュリティフレームワーク (CSF) のバージョン 1.1 （英語版）が 2018 年に公開されていましたが、今回、この CSF への準拠を目指す組織のために、ガイダンスとなる資料が更新され、日本語のホワイトペーパーも公開されたことをご紹介致します。 更新された NIST サイバーセキュリティフレームワーク (CSF): AWS クラウドにおける NIST CSF への準拠は、AWS のサービスやリソースを活用して CSF に準拠する組織の支援を目的としています。またこれは官民を問わず、中小企業から大企業まで、世界各地のあらゆる組織に役立つように作成されています。 この資料は CSF の更新のポイントが AWS の最新のサービスやリソースとどのように対応するのかを説明しており、独立した第三者評価機関による検証の新しい証明書も掲載しています。この証明書では、FedRAMP Moderate および ISO 9001/27001/27017/27018 の認証を取得している AWS のサービスがCSF に準拠していることが明示されています。 NIST CSF に馴染みのない方のために簡単に説明すると、このフレームワークは政府や民間から意見を集めて作成されたもので、リスクごとに実施すべき重点対策が示されています。CSF を活用することにより、識別、防御、検知、対応、復旧という 5 つの機能を中心としたセキュリティ対策の基盤を築き、セキュリティの強化、リスク管理の改善、組織の信頼性向上を実現できます。 CSF は当初、重要インフラの分野を対象としていましたが、今では規模の大小や種別を問わずあらゆる組織で活用、推奨される指針として、世界中の政府や産業界から支持されています。 この事からわかるように、NIST CSF は広い分野に適用可能なものです。国際標準化機構 (ISO) は 2018 年 2 月に「ISO/IEC 27103:2018 — […]

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

アプリケーションが進化してウェブに対してよりスケーラブルになるにつれて、お客様は柔軟なデータ構造とデータベースエンジンをそのユースケースに採用しています。現代のアプリケーションを構築するために NoSQL の柔軟なデータモデルを使用することから、NoSQL データストアを用いることがますます一般的になってきました。Amazon DynamoDB は高速で柔軟性のある NoSQL データベースサービスで、一貫して 1 桁ミリ秒のレイテンシーで大規模なサービスを提供しています。ウェブスケールのワークロードに DynamoDB を採用する際は、DynamoDB で利用できるセキュリティ管理を理解することが重要です。 DynamoDB を安全に実行するためにさまざまな機能を使用できます。Amazon VPC エンドポイントは、VPC で実行されているアプリケーションに DynamoDB テーブルへの安全なアクセスを提供します。また Amazon VPC エンドポイントは、AWS Identity and Access Management (IAM) を介してきめ細かいアクセス制御を提供し、DynamoDB テーブルに格納されたアイテムおよび属性へのアクセスを規制します。転送中のデータを暗号化するために Transport Layer Security (TLS) エンドポイントを使用することもできます。 保存データの暗号化には、テーブルを暗号化するために 2 つのカスタマーマスターキー (CMK) オプションのいずれかを選択できます。AWS が所有する CMK はデフォルトの暗号化タイプで、キーは CMK のコレクションとして AWS が所有し、複数の AWS アカウントでの使用を管理します。AWS が所有する CMK はお客様の AWS アカウントにはありません。一方、AWS が管理する […]