Amazon Web Services ブログ

Category: Security, Identity, & Compliance

Application Load BalancerがSNIを利用した複数のTLS証明書のスマートセレクションをサポートしました

本日、我々はApplication Load Balancer (ALB)でServer Name Indication (SNI)を使った複数のTLS/SSL証明書のサポートをリリースしました。これによって、単一のロードバランサの背後に、それぞれ別の証明書を持ったTLSで保護されたセキュアなアプリケーションを複数配置することが可能になります。SNIを利用するためには、複数の証明書をロードバランサの同じセキュアリスナーに紐付ける必要があります。ALBは各クライアントに最適なTLS証明書を自動的に選択します。これらの新機能は追加料金無しでご利用可能です。 もし新しい機能をどうやって使えばいいかを手っ取り早く知りたければ、こちらをクリックして下さい。この機能に興味があり、Transport Layer Security (TLS)について復習したい場合は続きをお読み下さい。 TLS? SSL? SNI? SSLとTLSは技術的には異なるものですが、これらを入れ替え可能な用語として使いがちです。SSLはTLSプロトコルの技術的な祖先にあたります。以下では簡潔さのために、TLSという用語を使っていきます。 TLSはパスワード、クッキー、クレジットカード番号といったデータを安全に伝送するためのプロトコルです。これによって、送信されるデータのプライバシー、認証、完全性が実現されます。TLSは、ウェブサイトのIDカードに相当する証明書を基礎とした認証技術を利用します。もし、その証明書を署名し発行した人、すなわちCertificate Authority (CA)を信用するなら、あなたはその証明書の中のデータは正しいと信用します。あるブラウザがTLSが有効化されたあなたのALBに接続するとき、ALBはあなたのサイトの公開鍵を表示しますが、それはCAによって暗号的に証明されたものになります。この方法によって、クライアントは”本物のあなた”からデータを得ていることと、あなたのサイトの公開鍵を利用して安全な接続を確立可能なことを確実にすることができます。 SNIのサポートによって、同一のALBで1つ以上の証明書をもっと簡単に利用できるようになりました。複数の証明書を使いたい最も一般的な理由は、同一のロードバランサで異なるドメインを捌きたいときです。これは、ワイルドカードやsubject-alternate-name (SAN)署名書をALBで利用することで元々実現可能ですが、いくつかの制約があります。ワイルドカード証明書は単純なパターンに合致する関連するサブドメインでしか使えません。SAN証明書は複数の異なるドメインをサポートできますが、単一の認証局でそれぞれを認証する必要があります。つまり、新しいドメインを追加するときには毎回証明書を再認証して再配布する必要があることを意味しています。 フォーラムやReddit、そして私のメールボックスで最も頻繁に頂いていた要望の1つが、TLSのServer Name Indication (SNI)拡張を利用してクライアント毎に証明書を選択するようにしてほしいというものでした。TLSはHTTPの下のトランスポートレイヤを担当するため、クライアントがリクエストしたホスト名を見ることができません。SNIはクライアントがサーバに”私が欲しい証明書はこのドメインです”というのを初回接続時に伝えることで動作します。これによってサーバはクライアントに返答するための適切な証明書を選択することができます。全てのモダンなウェブブラウザとその他のクライアントの大多数はSNIをサポートしています。実際、CloudFrontに接続しているクライアントの99.5%以上がSNIサポートしていることを今現在確認しています。 ALBの証明書スマートセレクション ALBの証明書スマートセレクションはSNIを越えていきます。正しいドメイン名の配列だけでなく、証明書にはサーバがサポートしている鍵交換方式と暗号、さらに証明書を署名する時に使った署名アルゴリズム (SHA2, SHA1, MD5)が含まれています。TLS接続を確立する時に、クライアントは”ClientHello”メッセージを送ることでTLSのハンドシェイクを開始しますが、そのメッセージにはクライアントが利用可能なプロトコルバージョン、拡張、暗号アルゴリズムの組、そして圧縮方式の概要が含まれています。各クライアントが何をサポートしているかを元に、ALBのスマートセレクションアルゴリズムがその接続のための証明書を選択し、クライアントに送ります。ALBは古典的なRSAアルゴリズムも、より新しくて人気で高速な楕円曲線ベースのECDSAアルゴリズムも両方サポートしています。クライアントのECDSAサポートはSNI程は広まっていませんが、全てのモダンなウェブブラウザではサポートされています。より高速でCPUの利用も少ないので、超低レイテンシなアプリケーションや、モバイルアプリのバッテリ残量の節約には特に有効です。ALBはTLSのハンドシェイクから各クライアントが何をサポートしているかが分かるので、同一ドメインのRSAとECDSA証明書の両方をALBにアップロードすることでALBが各クライアントに最適なものを自動的に選択させることができます。 ALBでSNIを利用する ここではウェブサイトの例として、VimIsBetterThanEmacs.comとVimIsTheBest.comを使います。Amazon Route 53でこれらのドメインを購入しホストしておいて、2つの別々の証明書をAWS Certificate Manager (ACM)で発行しています。もし1つのALBでこれらのサイトを両方とも安全に配信したいと思ったら、コンソールから両方の証明書を追加することができます。 最初に、コンソールから私のロードバランサを選択し、listenerタブに行き、”view/edit cerfiticates”を選択します。 次に、左上の角にある”+”ボタンを使って証明書を幾つか選択して、”Add”ボタンをクリックします。 これ以上の手順はありません。GUI好きな方ではなかった場合も、AWS Command Line Interface (CLI) (またはSDK)経由でももちろん新しい証明書を追加することはできますのでご安心下さい。 aws elbv2 add-listener-certificates –listener-arn <listener-arn> –certificates CertificateArn=<cert-arn> 知っておくべきこと ALBのアクセスログには、クライアントがリクエストしたホスト名と使われた証明書のARNが含まれるようになります。もし”hostname”のフィールドが空 (“-“で表現されます)だったときには、そのクライアントではリクエストにSNI拡張が使われていません。 […]

Read More

こんにちは、Amazon Macie: コンテンツを自動的に発見、分類、保護する

Jeffと私が初めてこのサービスを聞いたとき、私たちはMacieという名前の意味が知りたくなりました。もちろん偉大な研究者であるJeffは、Macieという名前を調べ、二つの意味があることを発見しました。フランス語とイギリス英語両方からの語源があり、典型的な少女の名前で、様々な意味を持っていました。Macieの一つめの意味は”武器”を意味する名前です。もう一つの意味は、力強く、さっぱりとした、優しい人の表す名前です。ある意味、これらの定義はふさわしいです。本日、私たちはAmazon Macieという新しいセキュリティサービスの提供開始を喜んで発表します。機械学習によって、AWS上に保存された機密情報の特定し、データ侵害、情報漏えい、Amazon Simple Storage Service (S3)への不正アクセスから保護をします。よって、Amazon Macieが、あなたの保存データを悪意のあるアクセスから保護する、”さっぱりとした”ユーザーインターフェースを備えた”優しい”サービスとして、AWS顧客にとって”力強い””武器”になることを私は想像できるのです。ふー、喋り過ぎました。たった一文でMacieの全てを表現するなんて!やはり、私はみなさんとAmazon Macieの凄さを共有するのに興奮しています。 Amazon Macieは、Amazon S3に保存されているデータを自動的に発見し分類する、機械学習を用いたサービスです。しかし、Macieはそれだけではありません。一度Macieであなたのデータが分類されれば、それらにビジネス価値が割り当てられ、継続的に監視し、アクセスパターンに基づいて疑わしい振る舞いを検知します。Macieの主要機能は以下です。 データセキュリティの自動化:データの分析、分類、処理し、過去のパターン、データに対するユーザー認証、データアクセス場所、アクセス時間を把握する データセキュリティと監視:利用ログデータの監視して異常検知したり、CloudWatch EventsやLambdaによってレポートされる問題を自動解決する プロアクティブなデータ保護のためのデータ可視性:保存データの詳細を管理者向けに可視化すると同時に、手動入力いらずで即時保護を提供する データ調査とレポート:管理者向けにレポーティングやアラートを構成可能にする どのようにAmazon Macieはこれらを実現するのか? 自然言語解析(NLP)の機械学習アルゴリズムを使って、MacieがS3バケットにあるデータの分類を自動化します。加えて、Amazon Macieはデータアクセスパターンを動的に分析する予測分類アルゴリズムも利用し、学習によって疑わしい振る舞いの可能性を知らせてくれます。Macieは個人特定情報(PII)や機密個人情報(SP)を検知するエンジンとしても動作します。MacieはAWS CloudTrailを利用しながら、継続的にS3バケットへのPUTリクエストのCloudTrailイベントを確認し、自動的に新しいオブジェクトの分類をほぼリアルタイムで行います。 MacieがAWSクラウド上のセキュリティやデータ保護にとって強力な道具であるだけでなく、ガバナンスやコンプライアンス要件、監査基準などにおいてもあなたを助けます。多くの人は既に、現時点でEUの最も厳しいプライバシー規制である、2018年5月25日に施行される一般データ保護規則(GDPR)を知っています。Amazon Macieは個人特定情報(PII)を認識し、ダッシュボードとアラート機能を提供することで、顧客にデータの暗号化や仮名化によるGDPRへの準拠を可能にします。Lambdaクエリと共に利用すると、MacieはGDPRの懸念に対応する協力な道具になります。 Amazon Macieサービスツアー それではAmazon Macieの詳細を見るためのツアーを開始しましょう。 まず最初に、私はMacieのコンソールにログインし、Macieのセットアップ処理を始めます。Get Startedボタンを押すことで私のデータの分類と保護を開始することができます。 下画面の通り、Amazon Macieサービスを有効化するには、このサービス用の適切なIAMロールを作成しなければなりません。また、私のアカウントでAWS CloudTrailを有効化する必要があるでしょう。 私はこれらのロールを作成し、私のアカウントでAWS CloudTrailサービスを有効化しました。Macieをより簡単にセットアップするために、Macieユーザーガイドから提供されているCloudFormationのサンプルテンプレートを利用することもできます。それは、必要なIAMロールとポリシーを作成するので、あとやるべきことはCoudTrailドキュメントに記載されている通りに証跡を設定するだけです。 もしあなたが複数のAWSアカウントをもっている場合は、Macieサービスを有効化したアカウントがマスターアカウントになることに注意してください。他のアカウントもMacieサービスと連携できますが、それらはメンバーアカウントということになります。メンバーアカウントのユーザーは、Macieコンソールにアクセスするために、マスターアカウントへフェデレートアクセスするためのIAMロールを使う必要があるでしょう。 さあ、IAMロールが作られ、CloudTrailが有効化されたら、Enable MacieボタンをクリックしてMacieによるデータ監視と保護を開始しましよう。 あるアカウントで一度Macieサービスが開始すると、サービス画面が表示され、そのアカウントにおける既存アラートが表示されます。今回、私はサービスを開始した直後なので、アラートはまだ存在していません。 Macieサービスのツアーで、ここから私のS3バケットとMacieを連携していきましょう。ただし、Macieが監視を開始するだけであれば、あなたはS3バケットを指定する必要はありませんでした。なぜならサービスは既に情報の分析や処理のためのAWS CloudTrail管理APIを使用しているからです。このMacieツアーでは、私は特定のバケットにおけるCloudTrailのいくつかのオブジェクトレベルAPIイベントを監視しようと思います。 S3と連携するために、MacieコンソールのIntegrationsタブに移動します。Integrationsタブでは、二つの選択肢:AccountsとServicesがあります。AccontsオプションはメンバーアカウントがMacieと連携するために使用され、あなたのデータ保存ポリシーを設定します。特定のS3バケットとMacieを連携したい時は、ServicesタブからServicesオプションをクリックします。 MacieとS3サービスを連携させると、証跡とS3バケットが作成され、S3データイベントに関するログが保存されます。始めるには、Select an accountドロップダウンを使いアカウントを選択します。アカウントが選択されると、連携可能なサービスが表示されます。Addボタンをクリックして、Amazon S3サービスを選択します。 さて、Macieに分析させたいバケットを選択したので、Review and Saveボタンを押して確認画面に行き、オブジェクトレベルロギングを行うことを確認してからSaveボタンをクリックします。 次に、このMacieツアーでは、どのようにMacieのデータ分類をカスタマイズするか見ていきましょう。 前述の通り、Macieは自動的にあなたのデータを監視し、分類します。Macieがあなたのデータを特定すると、ファイルとコンテントタイプでそのデータオブジェクトを分類します。また、Macieはサポートベクターマシン(SVM)も使用し、ファイルのメタデータに加えてS3オブジェクト内のコンテンツも分類します。深層学習/機械学習の研究分野において、サポートベクターマシンは教師あり学習モデルであり、データの分類や回帰分析のための学習アルゴリズムを持っています。Macieは、たくさんのコンテンツタイプのデータによってSVMを学習させ、あなたが書いたかもしれないソースコードが含まれていようとも、データコンテンツの正確な検知に最適化されます。 Macieはデータオブジェクトやファイルに対して一つのコンテンツタイプを割り当てますが、あなたはコンテンツタイプやファイル拡張子を有効化や無効化することもできます。それにより、それらオブジェクトをMacieサービスの分類対象に含めたり除外することができます。Macieがデータを分類したら、1から10までのリスクレベルがそのオブジェクトに割り当てられます。10が最もリスクが高く、1が最もリスクレベルが低いです。 Macieのデータ分類をカスタマイズするためには、Settingsタブに行きます。Macieの分類設定にて、有効化や無効化が可能な選択肢が表示されます。 このMacieツアーでの例として、File extensionを選んでみましょう。Macieが追跡し、分類に使用するファイル拡張子のリストが表示されます。 テストのために、Androidアプリケーションのインストールファイルであるapkファイル拡張子を編集し、ドロップダウンリストからNo […]

Read More

新機能- CloudTrailを全てのお客様に

Amazon Web Servicesをご利用の皆様に大変喜ばしいお知らせがあります。このお知らせが出来るまで辛抱強く待っていましたが、それも終わりです。 このたびAWS CloudTrailは、全てのお客様に対してあらかじめ有効にされるようになりました。 これにより、何も設定することなく過去7日間のAWSアカウント活動の可視性が提供されます。この新しい、常時有効となる機能には閲覧、検索、後述のCloudTrail Event Historyを通してのダウンロード機能が実装されています。 AWS CloudTrailの有用性をまだ得られてないお客様のために説明させてください。操作上のトラブルシューティングとレビュー、コンプライアンス、監査、セキュリティのための重要なサービスが、全てのお客様に対して提供されていることに興奮を覚えます。 AWS CloudTrailは、サポートされているAWSサービスに対するアカウント活動とイベントを記録します。 AWS CloudTrailは、あなたのAWSアカウントにおいてサポートされたAWSサービスのアカウント活動とイベントを捕捉し、Amazon Simple Storage Service(S3)、CloudWatch logsとCloudWatch Eventsにイベント・ログファイルを送ります。CloudTrailであなたはTrailを一般的につくれますし、その設定がアカウント活動とイベントの補足を可能にします。CloudTrailはまた、AWSアカウントで起こっているAPI活動に可視性を提供することによって、操作上のセキュリティ問題を分析することを可能にさせます。CloudTrailはマルチリージョン構成をサポートします。またCloudWatchとインテグレーションさせると、あなたはモニターしたいイベントのきっかけをつくることができたり、AWS Lambdaにアクティビティの記録を送るためのsubscriptionを生成するこができます。AWSコマンドラインインターフェース(CLI)、AWS Management Console、AWS SDKから、またAWSアカウントの他のAWSサービスからの呼び出しのデータの検索可能な履歴を得られることを、CloudTrailサービスを利用することは意味します。 AWS CloudTrailの主要な機能 Always On: 設定をする必要がなくあらかじめ全てのAWSアカウントで有効化され、全てのアカウント活動履歴の記録 Event History: 閲覧、検索、直近のAWSアカウント活動履歴のダウンロード Management Level Events: 詳細な管理活動情報の取得、例えば、EC2例またはS3バケツの作成、削除と修正 Data Level Events: Amazon S3オブジェクトにおける全てのAPIアクションとAPIアクションの詳細な情報の記録 Log File Integrity Validation: S3バケットに格納したログファイルの完全性の検査 Log File Encryption: あらかじめ、S3のサーバサイド暗号化機能を用いたS3バケットによる全てのログファイルの暗号化。オプションとしてAWS Key Management Service (AWS KMS)によるログファイルの暗号化 Multi-region Configuration: マルチリージョンからのログファイルの送信設定 AWS CloudTrailのさらなる機能をお知りになりたい場合は、製品詳細ページに記載があります。 私の同僚であるランダル・ハントが私に思い出させてくれました。つまり、お客様の課題の解決を援助するとき、CloudTrailは重要であるということです。ほとんどのAWSの人間、例えばテクニカル・エバンジェリスト・チームに所属する我々またはソリューションアーキテクトチームに所属する人間が言うのは、何が起きているのかという詳細を調べることができるようにCloudTrailを有効化する、ということです。ですのでこのリリースで、AWSコンソールまたはAWS CLI/APIを用いてすべてのお客様がアカウント活動を見ることができる(検索機能や、全てのサポートされたAWSサービスの活動の7日間のアカウント活動履歴をダウンロードする能力を含む)ことは、驚きに値しません。 CloudTrailはあらかじめ有効化されており、すべてのお客様は、現在CloudTrailにてログを取得することができ、またEvent […]

Read More

AWS CloudHSM アップデート – 重要データや規制に対応することが可能で、コスト効果の高いクラウド型のハードウェアベース キーマネージメント

AWSのお客様は、AWS上で驚くほど多様なミッションクリティカルなワークロードを実行しており、その多くは機密データを処理して保管しています。 「セキュリティプロセスの概要」のホワイトペーパーで詳しく説明しているように、AWSのお客様は、データを暗号化して保護するための方法について、複数のオプションから選択が可能です。 たとえば、Amazon Relational Database Service(RDS)は、サポートされているデータベースエンジン(MySQL、SQL Server、Oracle、MariaDB、PostgreSQL、およびAurora)ごとにオプションがあり、転送中のデータの暗号化もサポートしています。 多くのお客様がAWS Key Management Service(KMS)を使用してキーを集中管理したり、AWS CloudHSMが提供するハードウェアベースの鍵管理、暗号化、復号を利用することで、重要データと規制に対応したワークロードはコンプライアンスの要求に応えることができています。(ハードウェアセキュリティモジュール(HSM)について、詳しくは、 AWS CloudHSM – Secure Key Storage and Cryptographic Operationsを参照してください)。   主要なCloudHSMアップデート 今日、私たちが第1世代の製品から学んだことを踏まえて、我々はCloudHSMを大幅にアップデートしました。専門的な運用ノウハウの必要性を軽減し、ハードウェアベースのキー管理の利点をより多くのユーザーに提供できるように、改良しました。改善の要約を以下に示します。 従量課金モデル – CloudHSMは、シンプルで費用対効果の高い、初期費用なしの従量課金モデルで提供します。 フルマネージド – CloudHSMはスケーラブルな管理サービスになりました。プロビジョニング、パッチ適用、高可用性、およびバックアップはすべて組み込まれています。スケジュールされたバックアップは、(HSMハードウェアだけが知っている鍵を使用して)ハードウェアからHSMの暗号化イメージを抽出し、AWS内の同一のHSMハードウェアにのみリストアできます。耐久性のために、これらのバックアップはAmazon Simple Storage Service(S3)に保存され、AWS KMSマスターキーを使用してサーバーサイドのS3暗号化を使用して再度暗号化されたセキュリティ層が追加されます。 オープンかつ互換性を考慮 – CloudHSMはオープンで標準に準拠しており、PKCS#11、Java Cryptography Extension(JCE)、および、Microsoft CryptoNG(CNG)など、複数のAPI、プログラミング言語、および暗号化拡張機能をサポートしています。 CloudHSMのオープン性により、キーを(暗号化された形式で)1つのCloudHSMから別のCloudHSMに移動するプロセスをより詳細かつ簡単に制御し、他の市販のHSMとの間で移行することができます。 より安全に – CloudHSM Classic(オリジナルモデル)は、FIPS 140-2レベル2に準拠した鍵の生成と使用をサポートしています。我々は、HSMにアクセスまたは変更するための物理的な試行を検出して対応するように設計されたセキュリティー・メカニズムを備え、FIPS 140-2レベル3を段階的にサポートしています。バーチャルプライベートクラウド(VPC)内に改ざん防止を備えたHSMに対して、排他的なシングルテナントアクセスとしており、お客様のキーは保護されます。 CloudHSMは、重要な管理機能と鍵管理機能のためのクォーラム認証をサポートします。この機能を使用すると、機能にアクセスできるN個の可能なIDのリストを定義され、少なくともM人以上がアクションを承認する必要があります。また、提供するトークンを使用したマルチファクタ認証もサポートしています。 AWS-Native – アップデートされたCloudHSMはAWSに統合されており、他のツールやサービスとうまく連携します。 AWS管理コンソール、AWSコマンドラインインターフェイス(CLI)、またはAPI呼び出しを使用して、HSMのクラスタを作成および管理できます。   使ってみましょう 1〜32のHSMで構成されたCloudHSMクラスターを作成できます。それぞれのクラスターは、特定のAWSリージョンの別々のアベイラビリティゾーンにあります。 AZをまたいでHSMを展開することで、高可用性(組み込みロードバランシングを含む)を実現できます。また、より多くのHSMを追加すると、スループットの向上が得られます。 […]

Read More

AWS WAF 用のレートベースのルールでウェブサイトとサービスを保護

AWS WAF (ウェブアプリケーションファイアウォール) は、悪質または不正なリクエストに関与する様々なタイプのアプリケーションレイヤー攻撃からアプリケーションを保護するために利用できます。このサービスについて説明したブログ (「新しい AWS WAF について (New – AWS WAF)」でもお見せしましたが、クロスサイトスクリプティング、IP アドレス、SQL インジェクション、サイズ、コンテンツ制約に見合うルールを定義できます。 受信リクエストがルールと一致すると、アクションが呼び出されます。アクションは許可やブロックを実行したり、単にマッチ数をカウントすることができます。既存のルールモデルはパワフルかつ様々な種類の攻撃を検出し対応することができます。ただし、特定の IP アドレスから送られた有効なリクエストが大量に送信されただけのケースでは、攻撃として対応することはできません。こうしたリクエストはウェブレイヤーの DDoS 攻撃や総当たりのログインの試行、もしくはパートナー統合で不具合があった場合の可能性があります。 新しいレートベースのルール 本日、WAF にレートベースのルールを追加しました。これにより、ブラックリストへの IP アドレスの追加または削除を管理できるようになり、例外や特別なケースに対応できる柔軟性も提供します。IP アドレスをブラックリストに追加 – 設定済みのしきい値を超える速度でリクエスト数を送信した IP アドレスをブラックリストに追加することができます。IP Address のトラッキング– どの IP アドレスがブラックリストに追加されているか見ることができます。IP Address の削除 – ブラックリストに追加された IP アドレスは、設定済みのしきい値を超える速度でリクエストを送信しないようになれば自動的にリストから削除されます。IP Address の例外 – 特定の IP アドレスをブラックリストの対象外として設定することができます。その場合はレートベースのルール内にある IP アドレスのホワイトリストを使用してください。たとえば、自分のサイトに信頼できるパートナーが高速でアクセスできるように許可したい場合もあるでしょう。モニタリングおよびアラーム発行 – 各ルールに発行した CloudWatch メトリクスでモニタリングしたりアラーム発行をすることができます。新しいレートベースのルールと WAF の条件を組み合わせて高度なレート制限戦略を取り入れることもできます。たとえば、レートベースのルールやログインページと一致する WAF […]

Read More

Cloud Directory の更新 – Typed Links のサポート

今年始めに公開したブログ「Cloud Directory – 階層データの AWS クラウドネイティブディレクトリ (Cloud Directory, our cloud-native directory for hierarchical data)」では、厳密に型指定された入力の階層データを大量保存できるように設計された方法について説明しました。Cloud Directory は何百万というオブジェクトを保存するようにスケールできるので、様々なクラウドアプリケーションやモバイルアプリケーションに最適です。最初のブログ投稿では、どのようにして各ディレクトリに 1 つ以上のスキーマがあるか、そしてそれにより 1 つまたはそれ以上のファセットがあるかについて説明しました。各ファセットは、オブジェクトの必須の属性および許容される属性の一連を定義します。 Typed Links の概要 本日より、Typed Links のサポートを追加することで Cloud Directory モデルの表記枠を拡大しました。次のリンクを使用して複数の階層に渡りオブジェクトとオブジェクトの関係を作成できます。ディレクトリにある複数のタイプのリンクをそれぞれ定義することができます (各リンクの種類はディレクトリと関連付けているスキーマ 1 つの個別ファセットです)。タイプの他に、各リンクには一連の属性を与えることができます。Typed Links は、他のオブジェクトと関係する既存のオブジェクトを不注意に削除しないようにすることで、参照データの整合性を維持する上で役立ちます。たとえばロケーション、ファクトリー、フロア番号、ルーム、マシン、センサーなどのディレクトリがあるとします。こうした情報はそれぞれ階層内で豊富なメタデータ情報を含む Cloud Directory のディメンションとして表示することが可能です。Typed Links を定義し使用することで、様々な方法でオブジェクトを連携させたり、メンテナンス要件に繋がる Typed Links の作成、サービス記録、保証、安全情報などをリンクの属性を使用してソースオブジェクトと対象オブジェクト間の関係の追加情報を保存できます。そしてリンクタイプや属性の値をベースにクエリを実行することができます。たとえば、過去 45 日以内に消去されていないすべてのセンサーや、保証期間が過ぎたモーターをすべて探すことができます。指定されたフロアにあるすべてのセンサーを探したり、指定されたタイプのセンサーがあるフロアすべてを探すことができます。 Typed Links を使用する Typed Links を使用するには、1 つ以上の Typed Link ファセットをスキーマに追加します。追加するには CreateTypedLinkFacet関数を呼び出します。次に […]

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

Amazon Inspector の更新 – 評価レポート、プロキシサポートなど

は当社の自動セキュリティ評価サービスです。このサービスは AWS で実行するアプリケーションの動作を分析し、セキュリティ問題を識別する上で役立ちます。Inspector については 2015 年の後半にこのブログで紹介し、その使い方についてご説明したことがあります (「Amazon Inspector – 自動セキュリティ評価サービス (Amazon Inspector – Automated Security Assessment Service)」)。同サービスを使うには、まずタグを使用してアプリケーションを生成する AWS リソースのコレクションを定義します。次に、セキュリティ評価テンプレートを作成し評価の一部として実行したい一連のルールを特定します。 評価ターゲットとセキュリティ評価テンプレートを作成したら、クリック 1 つでターゲットリソースに対して実行することができます。この評価は Linux と Windows ベースの EC2 インスタンスで実行するエージェントを活用します (詳細については「AWS エージェント (AWS Agents)」をご覧ください)。評価は手動で実行したり、 を使用して既存の発券システムに結果を転送することができます (手順については「Amazon Inspector でセキュリティ脆弱性テストをスケールする (Scale Your Security Vulnerability Testing with Amazon Inspector)」をご覧ください)。実行するインスタンスが 1 件または何千件とある場合でも、定期的かつ頻繁に評価を行うことをおすすめします。デプロイや統合インスタンスといった DevOps パイプラインの一部として実行できます。そうすることで、セキュリティ評価テンプレートの作成時に選択したルールパッケージによる条件に見合った本稼働環境で、コードやシステムを安心してデプロイすることが可能になります。また、設定ドリフトを回避するため、本稼働システムに対しても頻繁に評価を実行することをおすすめします。Amazon Inspector には、次の強力な新機能を追加したばかりです。 評価レポート – 新しい評価レポートはエグゼクティブサマリーから始まり、評価の総合的な概要を提供します。このレポートはチームやリーダーシップとの共有そしてコンプライアンス監査のドキュメントとしても使用できるように作成されています。 プロキシのサポート – […]

Read More

発表: Amazon Athena が暗号化されたデータのクエリのサポートを追加

昨年 11 月に、当社は毎日膨大な量のデータに安全にアクセスして調べる必要があるお客様を支援するための重要なステップとなることを期待して、サービスをマーケットに投入しました。このサービスは Amazon Athena にほかなりません。私はこれを、オブジェクトストレージのクエリにより「1 回のジャンプで背の高いクエリを飛び越える」ことを試みるマネージド型サービスであると考えています。AWS のお客様が、Amazon S3 に保存された大量のデータを簡単に分析してクエリを実行できるようにするサービスです。 Amazon Athena は、ユーザーが標準 SQL を使用して Amazon S3 のデータを簡単に分析できるようにする、サーバーレスでインタラクティブなクエリサービスです。Athena の中核となるのは、ANSI SQL のサポートによりクエリを実行する分散 SQL エンジンの Presto と、Athena が CSV、JSON、ORC、Avro、Parquet などのよく使用されるデータ形式に対応できるようにし、create table、drop table、alter table などのよく使用されるデータ定義言語 (DDL) オペレーションを追加する Apache Hive です。Athena は、構造化されたデータ形式および構造化されていないデータ形式で Amazon Simple Storage Service (S3) に保存されたデータセットへのパフォーマンスの高いクエリアクセスを可能にします。Hive 対応 DDL ステートメントと ANSI SQL ステートメントは、AWS マネジメントコンソールから、または Athena JDBC ドライバーをダウンロードして利用することで SQL […]

Read More

AWS KMSを使用してAmazon Kinesisレコードを暗号化および復号する

コンプライアンスやデータセキュリティの要件が厳しいお客様は、AWSクラウド内での保存中や転送中など、常にデータを暗号化する必要があります。この記事では、保存中や転送中もレコードを暗号化しながら、Kinesisを使用してリアルタイムのストリーミングアプリケーションを構築する方法を示します。 Amazon Kinesisの概要 Amazon Kinesisプラットフォームを使用すると、要求に特化したストリーミングデータを分析または処理するカスタムアプリケーションを構築できます。 Amazon Kinesisは、ウェブサイトクリックストリーム、金融取引、ソーシャルメディアフィード、ITログ、トランザクショントラッキングイベントなど、何十万ものソースから1時間につき数テラバイトのデータを連続的にキャプチャして保存できます。 Amazon Kinesis Streamsは、HTTPSを使用してクライアント間でデータを暗号化し、転送されているレコードの盗聴を防止します。ただし、HTTPSで暗号化されたレコードは、データがサービスに入ると解読されます。このデータは24時間保管され(最大168時間まで延長可能)、アプリケーションの処理、再処理、処理遅延の際の巻き取りに対して十分なゆとりが確保されています。 ウォークスルー Amazon Kinesis Producer Library(KPL)、Kinesis Consumer Library(KCL)、AWS KMS、aws-encryption-sdkを使用してサンプルKinesisプロデューサおよびコンシューマアプリケーションへの暗号化と復号を行います。この記事で使用されているKinesisレコードの暗号化と復号に使用される方法とテクニックは、あなたのアーキテクチャに簡単に再現できます。いくつか制約があります: AWSは、暗号化と復号のためのKMS APIリクエストの使用料金を請求します。詳しくは、「AWS KMSの料金」を参照してください。 Amazon Kinesis Analyticsを使用して、このサンプルアプリケーションのクライアントによって暗号化されたレコードのAmazon Kinesis Streamにクエリすることはできません。 アプリケーションでレイテンシの低い処理が必要な場合は、レイテンシに多少の上乗せがあることに注意してください。 次の図は、ソリューションのアーキテクチャを示しています。

Read More