Amazon Web Services ブログ

Category: AWS Elastic Beanstalk

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

by AWS Japan Staff | on 17 MAY 2017 | in Amazon EC2, Amazon EC2 Systems Manager, Amazon Inspector, Amazon WorkSpaces, AWS Directory Service, AWS Elastic Beanstalk, セキュリティ | Permalink

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 MS17-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

AWS Elastic Beanstalkに関しては、2017 年5月4日以降のWindowsサーバーで構築された環境は、本問題の影響を受けません。ただし、既存のElastic Beanstalk Windows環境のアップデートは常に推奨しています。AWS管理コンソールから、もしくは、環境を再構築することでアップデート可能です。Elastic Beanstalkの現時点での最新のリリースノートはこちらです。

AWSによるセキュリティ速報(原文)は、こちらをご覧ください。

AWSサービスの効果的な使い方

Amazon Inspectorは、Amazon EC2インスタンスに対してエージェントを導入し、セキュリティ診断を行うサービスです。CVE(共通脆弱性識別子)のルールパッケージに基づいた診断も可能で、WannaCryに関連するCVE-2017-0143からCVE-2017-0148の脆弱性の検証ができます。AWS管理コンソール、CLI、APIから診断を実行できます。診断結果は、AWS管理コンソールで表示したり、エグゼクティブサマリー含むPDF形式のレポートとしても取得できます。

AWSコンソール上でのAmazon Inspector 結果一覧画面例

AWSコンソール上でのAmazon Inspector 結果詳細画面例

詳しくは、Amazon Inspector ユーザーガイドをご覧ください。

Amazon EC2 Systems Managerは、Amazon EC2インスタンスおよびオンプレミスサーバーに対してエージェントを導入し、ソフトウェアインベントリ収集やOSパッチ適用、OS構成変更などを一元的に管理できるサービスです。インスタンスに対して、シェルスクリプトやPowerShellコマンドの実行、パッチ適用の時間指定や定期実行などの管理タスクを簡単に自動化できます。今回のような、Windowsのセキュリティ更新プログラム適用にもご利用いただけます。詳しくは、Amazon EC2 Systems Manager ユーザーガイドをご覧ください。

推奨するAWSソリューション

今回のようなランサムウェアに対する最も有効な対策は、常日頃からバックアップを取得・管理し、セキュリティ推奨構成を保っておくことです。AWSではバックアップ&復旧に関する各種ソリューションの情報が提供されています。

EBS Snapshot Scheduler – Amazon EC2にアタッチされているブロックストレージ(EBS)のバックアップをスケジュール管理できます
https://aws.amazon.com/answers/infrastructure-management/ebs-snapshot-scheduler/
Securing Windows EC2 Instances – EC2をセキュアに保つための推奨構成ガイドです
https://aws.amazon.com/answers/security/aws-securing-windows-instances/

上記の情報も参考に、これからも安心・安全なAWSライフをご満喫ください。

桐山隼人, セキュリティソリューションアーキテクト
坪和樹, クラウドサポートエンジニア
長谷川淳, クラウドサポートエンジニア

最新リリース: AWS Elastic Beanstalk でカスタムプラットフォームのサポート開始

by AWS Japan Staff | on 23 FEB 2017 | in AWS Elastic Beanstalk | Permalink

うれしいお知らせです。AWS Elastic Beanstalk でカスタムプラットフォームを作成できるようになりました。この最新リリースの AWS Elastic Beanstalk により、開発者やシステム管理者は、AWS Elastic Beanstalk のカスタムプラットフォームイメージを独自に作成して管理し、インスタンス設定を完全にコントロールできます。ご存じのように、AWS Elastic Beanstalk は、一般的なウェブプラットフォームでウェブアプリケーションやサービスをデプロイ、スケーリングするためのサービスです。このサービスでは、ユーザーがコードをアップロードするだけで、デプロイメント、容量のプロビジョニング、負荷分散、Auto Scaling が自動的に処理されます。

これまでの AWS Elastic Beanstalk で提供していたのは、事前設定済みのプラットフォームのセットです。さまざまなプログラミング言語、Docker コンテナ、上述した用途別のウェブコンテナの設定が複数用意されていました。Elastic Beanstalk では、選択された設定に従って、1 つ以上の Amazon EC2 インスタンスで対象のアプリケーションを実行するためのソフトウェアスタックやリソースをプロビジョニングしていました。この最新リリースでは、独自のカスタマイズした Amazon Machine Image (AMI) からプラットフォームを作成できます。カスタムイメージは、サポートされているオペレーティングシステム (Ubuntu、RHEL、Amazon Linux) のいずれかで構築できます。これらの特化された Elastic Beanstalk プラットフォームの作成作業は、マシンイメージ作成ツールの Packer で簡素化できます。Packer は、すべての主要オペレーティングシステムで実行するオープンソースツールであり、1 つの設定から複数のプラットフォームのマシンイメージやコンテナイメージを作成できます。カスタムプラットフォームでは、Elastic Beanstalk 環境全体にわたり、標準化とベストプラクティスを適用して管理できます。たとえば、Ubuntu や Red Hat Enterprise で独自のプラットフォームを作成し、Elastic Beanstalk で現在サポートされていない言語やフレームワーク (Rust、Sinatra など) を使用してインスタンスをカスタマイズできます。

カスタムプラットフォームの作成
カスタムプラットフォームを作成するには、最初に Packer テンプレートを作成します。Packer テンプレートを作成したら、プラットフォーム定義ファイルの platform.yaml ファイル、プラットフォームのビルダータイプを定義するプラットフォームフック、およびスクリプトファイルを作成します。これらのファイルが準備できたら、プラットフォーム定義アーカイブと呼ばれる zip アーカイブファイルを作成して、これらのファイル、関連するスクリプト、その他 Amazon Machine Image (AMI) の構築に必要な追加のアイテムをパッケージ化します。プラットフォーム定義アーカイブを構築するための基本的なフォルダ構造は以下のとおりです。

\|– ビルダー	カスタムプラットフォームを作成するために Packer で使用するファイルを収容
\|– custom_platform.json	Packer テンプレート
\|– platform.yaml	プラットフォーム定義ファイル
\|– ReadMe.txt	サンプルの説明

Elastic Beanstalk の新しいカスタムプラットフォーム機能を詳しく知るには、実際に試してみるのが最善です。Packer を使用してカスタム AMI とプラットフォームを構築してみましょう。まず、カスタム Packer テンプレートを構築します。Packer サイトにアクセスし、Packer ツールをダウンロードして、このバイナリが環境パスに追加されたことを確認します。

次にテンプレートを構築しましょう。Packer テンプレートは、構築するイメージを定義するための JSON 形式の設定ファイルです。Visual Studio を開いて、これを IDE として使用し、Packer テンプレートを構築するための新しい JSON ファイルを作成します。

Packer テンプレート形式には、イメージのさまざまなコンポーネント用に設計されたキーのセットがあります。以下のキーが提供されています。

variables (オプション): ユーザー変数を定義する 1 つ以上のキーと値の文字列
builders (必須): マシンイメージおよび各イメージの設定を作成するためのビルダーを定義する配列
provisioners (オプション): マシンイメージのソフトウェアをインストールおよび設定するための provisioner を定義する配列
description (オプション): テンプレートの説明としての文字列
min_packer_version (オプション): テンプレートの解析に必要な最小の Packer バージョンを示す文字列
post-processors (オプション): イメージの構築の完了後に行う後処理ステップを定義する配列

カスタム Elastic Beanstalk プラットフォーム用のカスタムイメージを作成する際に利用できるサンプルの Packer テンプレートについては、Elastic Beanstalk ドキュメントで有効な Packer テンプレートのサンプルを参照してください。テンプレートで、スクリプトの場所とスクリプトの実行に必要なコマンドの情報を指定し、ビルドスクリプトを実行するための provisioner を追加して Node をインストールします。完成した JSON ファイル、tara-ebcustom-platform.json は、以下のとおりです。

次に、構築した Packer テンプレートをコマンドラインで検証します。

幸いなことに、この Packer テンプレートはエラーになります。テンプレートに指定したスクリプト、eb_builder.sh がビルダーフォルダにあるとしたことが原因です。しかし、ビルダーフォルダは作成していません。また、シェルスクリプトを Packer テンプレートに指定してもいません。ファイルがエラーになって幸いだとは不信に思われるかもしれません。これが幸いだという理由は、Elastic Beanstalk サービスにテンプレートをアップロードする前に、テンプレート内のエラーやマシンイメージの構築に必要なファイルの不足を検出できるからです。ビルダースクリプトのフォルダとファイルを作成して、これらのエラーを修正することにします。Elastic Beanstalk ドキュメントに提供されているサンプルスクリプトを使用して、上記構造の Dev フォルダを作成します。カスタム Elastic Beanstalk プラットフォームの作成に関する限り、このサンプルスクリプトはプラットフォームフックと呼ばれます。プラットフォームフックは、ライフサイクルイベント中、および管理オペレーションに応じて実行されます。このカスタムプラットフォームの実装で使用したビルダースクリプトのサンプルを以下に示します。

このビルダーフォルダ構造には、カスタムプラットフォームを構築するためのビルダースクリプト、プラットフォームフック、その他の (プラットフォームスクリプトと呼ばれる) スクリプトが入っています。プラットフォームスクリプトは、環境変数や他のプラットフォームフック内の情報を取得するために使用できるシェルスクリプトです。プラットフォームフックは、ビルダーフォルダのサブフォルダ内にあり、その構造は以下のとおりです。

以上の Packer テンプレート、platform.yaml、ビルダースクリプト、プラットフォームフック、setup ファイル、config ファイル、プラットフォームスクリプトのすべてが、以下に示すビルダーフォルダ内のプラットフォーム定義を構成します。

サンプルの .yaml ファイルに提供されている platform.yaml を利用し、これを適切に変更してカスタム Elastic Beanstalk プラットフォームの実装に使用します。その結果として完成した platform.yaml ファイルは以下のとおりです。

version: "1.0"

provisioner:
  type: packer
  template: tara-ebcustom-platform.json
  flavor: amazon

metadata:
  maintainer: TaraW
  description: Tara Sample NodeJs Container.
  operating_system_name: Amazon linux
  operating_system_version: 2016.09.1
  programming_language_name: ECMAScript
  programming_language_version: ECMA-262
  framework_name: NodeJs
  framework_version: 4.4.4
  app_server_name: "none"
  app_server_version: "none"

option_definitions:
  - namespace: "aws:elasticbeanstalk:container:custom:application"
    option_name: "NPM_START"
    description: "Default application startup command"
    default_value: "node application.js"

この Packer テンプレートを再度コマンドラインで検証します。

後は EB CLI を使用してプラットフォームを作成するだけです。この機能は、EB CLI バージョン 3.10.0 以降で利用できます。EB CLI は、こちらからインストールできます。Elastic Beanstalk 開発者ガイドの指示に従ってください。EB CLI を使用してカスタムプラットフォームを作成するには、プラットフォーム定義アーカイブから抽出したファイルが含まれているフォルダを選択します。このフォルダについては、以下のステップを実行する必要があります。

EB CLI を使用してプラットフォームリポジトリを初期化し、プロンプトに従う
- eb platform init または ebp init
テンプレートおよびスクリプトを使用して Packer 環境を起動する
- eb platform create または ebp create
IAM ロールがインスタンスに対して正常に作成されたことを検証する。このインスタンスプロファイルロールは、EB create プロセスを通じて自動的に作成されます。
- aws-elasticbeanstalk-custom-platform-ec2-role
プラットフォームの作成ステータスを検証する
- eb platform status または ebp status

次にコマンドラインに移動し、eb platform init コマンドを実行して EB CLI コマンドでプラットフォームを初期化します。

次のステップとして、EB CLI を使用してカスタムプラットフォームを作成します。そのために、プラットフォームフォルダの短縮コマンド、ebp create を実行します。

成功! カスタム Elastic Beanstalk プラットフォームが作成されました。このプラットフォームをウェブソリューションとしてデプロイできます。カスタムプラットフォームを作成する際に重要な点は、Packer を実行する EIP を使用せずに、単一のインスタンス環境を起動することです。この環境は、必要に応じて複数のプラットフォームおよび各プラットフォームの複数のバージョンに再利用できます。さらに、カスタムプラットフォームはリージョン固有です。Elastic Beanstalk を複数のリージョンで使用する場合は、リージョンごとに別個のプラットフォームを作成する必要があります。

カスタムプラットフォームのデプロイ
カスタムプラットフォームを作成したら、AWS CLI または AWS Elastic Beanstalk コンソール経由でアプリケーションをデプロイできます。作成済みのカスタムプラットフォームを使用して環境を作成することは、Create New Environment ウィザードでのみ可能です。[Create a new environment] ウェブページで、[Platform] の [Custom Platform] ラジオボタンをオンにすると、作成済みのカスタムプラットフォームを選択できます。表示されるカスタムプラットフォームのリストから、前に作成したカスタムプラットフォームを選択します。

EB CLI で最新バージョンのカスタムプラットフォームをデプロイすることもできます。作成済みのカスタムプラットフォームをデプロイするためのコマンドラインは、以下のようになります。

eb deploy -p tara-ebcustom-platform

まとめ
Elastic Beanstalk のカスタムプラットフォームの構築は今すぐ開始できます。Elastic Beanstalk またはカスタムプラットフォームの詳細については、AWS Elastic Beanstalk 製品ページまたは Elastic Beanstalk 開発者ガイドを参照してください。

– Tara

AWS Elastic Beanstalk 管理されたプラットフォームの更新

by AWS Japan Staff | on 20 APR 2016 | in AWS Elastic Beanstalk, General | Permalink

アプリケーションが動作するAWS Elastic Beanstalkの環境を、指定したメンテナンス時間帯に、自動的に最新のバージョンに更新するよう選択出来るようになりました。Elastic Beanstalkは、サポートされるプラットフォーム（Java, PHP, Ruby, Node.js, Python, .NET, Go, およびDocker)の新しいバージョンを定期的にリリースしています。こちらには、オペレーティングシステム、ウェブおよびアプリケーションサーバ、言語やフレームワーク等の更新も含まれます。以前は、Elastic Beanstalkコンソール、コマンドラインインタフェース（CLI）、またはAPIを使って手動でElastic Beanstalkの環境の更新を開始しなければいけませんでした。本日より、シンプルに1週間ごとにメンテナンス時間帯を選択して、その時間帯で自動的に環境のプラットフォームバージョンを更新させることが出来るようになりました。

管理されたプラットフォームの更新により、アプリケーションを動作させるプラットフォームへパッチ適用したり、更新し続けるようを気を付ける必要はなくなりました。Elastic Beanstalkは、エンドユーザーへの影響は最小限になるように安全な形で更新を行います。この更新はimmutableデプロイメントメカニズムを使用します。こちらにより、Elastic Beanstalkは同様のAmazon EC2インスタンス群を起動して、環境を交換して既存のインスタンスを終了する前に更新をインストールします。もしElastic Beanstalkのヘルスシステムが更新の間に問題を検知した場合には、アプリケーションのエンドユーザーへのインパクトを最小限に保ちつつ、既存のインスタンス群にトラフィックを向け直します。

Elastic Beanstalkは新しいパッチとマイナープラットフォームのバージョンの更新を自動的に実行できます。環境ごとに異なるメンテナンス時間帯をスケジュール可能です。また定期的にスケジュールが組まれたメンテナンス時間帯以外でアップデートを開始させることも可能です。Elastic Beanstalkは、(例：Java 7 Tomcat 7 からJava 8 Tomcat 8への）メジャーバージョンアップデートを自動的に実行しません。その理由は、メジャーバージョンののアップデートには非互換の変更や追加のテストが必要な場合があるためです。こちらの場合は、手動でアップデートを開始する必要があります。

利用開始するには、Elastic Beanstalkコンソールの設定タブ、EB CLIまたはAPIで、管理されたプラットフォームの更新を有効にしなければなりません。管理されたプラットフォームの更新についての詳細は、ドキュメントまたはFAQをご覧ください。

Elastic Beanstalkの詳細：

翻訳は舟崎が担当しました。原文はこちらです。

AWS Elastic Beanstalk で、 2つの新しいデプロイメントポリシーとAmazon Linux AMI 2016.03 が利用可能に

by AWS Japan Staff | on 11 APR 2016 | in AWS Elastic Beanstalk | Permalink

AWS Elastic Beanstalk を利用してアプリケーションコードをデプロイする際に、immutable, rolling with additional batch という 2つの新たなデプロイメントポリシーを利用可能になりました。これは、現在 Elastic Beanstalk がサポートしている2つの既存のデプロイメントポリシー(rolling, all at once) に追加されるものです。アプリケーションを更新する際に、これらの4つのポリシーから、1つ選択できます。これらの 4つのデプロイメントポリシーに加えて、 Elastic Beanstalk では、 DNS ベースの Blue/Green アップデートも利用できます。

Elastic Beanstalk 上のアプリケーションや環境設定を更新する際に、新たなデプロイメントポリシーである immutable を利用できます。このポリシーは、ダウンタイムを細小にしたり、デプロイメントの失敗によるリスクを小さくしたい商用環境でのアップデートに非常に向いています。このポリシーを利用することによって、デプロイメントの失敗による影響を1つのインスタンスに限定したり、更新中にあなたのアプリケーションがフルキャパシティでトラフィックをさばいたりすることが可能になります。このポリシーでは、新たに作成される一台のAmazon EC2 インスタンスにコードをデプロイし、新しいバージョンを実行する新規インスタンス群の全台が起動される前に、ヘルスチェックに通るか確認します。ひとたび、新しいアプリケーションバージョンを実行する新規インスタンス群が起動されると、古いインスタンス群は終了されます。

また、アプリケーションを更新する際に、新たなデプロイメントポリシーである rolling with additional batch を利用できます。このポリシーを利用することによって、デプロイメントの失敗による影響を単一バッチに限定したり、更新中にあなたのアプリケーションがフルキャパシティでトラフィックをさばいたりすることが可能になります。このポリシーでは、既存のインスタンス群からなる各バッチに更新を展開する前に、新規に作成される EC2 インスタンスからなるバッチにコードをデプロイします。デプロイメントの終わりに、古いアプリケーションバージョンを実行する最後のバッチを終了します。例えば、もしあなたが、あなたのアプリケーションを実行する 9台の EC2 インスタンスを持っていて、1/3 ずつ更新するように選択した場合、本ポリシーにより、まずはじめに3台の新バージョンを実行する新規インスタンスが作成されます。新規インスタンス群(バッチ)がヘルスチェックに成功すると、 Elastic Beanstalk は、古いインスタンスのうちの6台を、2回にわけて連続で更新していきます。古いバージョンを実行する残りの3台を終了します。

加えて、Elastic Beanstalk でサポートされる全ての Linux プラットフォームが、 2016.03 Amazon Linux AMI に更新され、環境名に使用できる文字数が、23 文字から 40文字に引き上げられました。

新しいデプロイメントポリシーを使用するには、プラットフォームバージョンが、2.1.0以降である必要があります。デプロイメントポリシーの選択は、 Elastic Beanstalk コンソール、 Elastic Beanstalk CLI, もしくは、SDK から可能です。デプロイメントポリシーに関する詳細は、ドキュメント(2016/4/11現在、英語版のみ記載)を確認してください。

Elastic Beanstalk の情報については下記より確認可能です:

翻訳は江川（@daiti0804）が担当しました(原文はこちらです)。