Amazon Inspectorがkernelの古い脆弱性を検出し続ける

現象

Linux EC2でkernelのセキュリティアップデートを適用したにもかかわらず、Inspectorが相変わらず古いkernelの脆弱性を検出する。
何ヶ月か運用していくと、ある程度古いkernelの脆弱性は検出されなくなるんだけど、さっき適用したkernelアップデートで解消するはずの脆弱性は引き続き検出されて「?」な事態に。

原因

Inspectorは実行中のkernelのバージョンではなく、サーバにインストールされているすべてのkernelのバージョンについて脆弱性の有無をチェックしている。
通常、kernelのバージョンアップを実行しても古いバージョンのkernelはすぐには削除されず、サーバ上に何世代かはバックアップされている。

CentOSなら /etc/yum.conf に世代数が設定されている。
参考 https://qiita.com/testnin2/items/2946cc6bc54b0de96221

続きを読む

業務でawsを使っていたらCloudTrailを設定しよう

awsを使っていたらCloudTrailを設定しよう

CloudTrailとは

  • AWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を可能にするサービスです。(公式)

CloudTrail-01-HeaderPic-v2-small.png

できること

  • アカウントアクティビティをログに記録し、継続的に監視し、保持できます。
  • SDK やコマンドラインツール、その他の AWS のサービスを使用して実行されるアクションなど、AWS アカウントアクティビティのイベント履歴を把握できます。
  • このイベント履歴により、セキュリティ分析、リソース変更の追跡、トラブルシューティングをより簡単に実行できるようになります。

メリット

コンプライアンスの簡素化

  • アカウント内で行われた操作のイベントログが自動的に記録および保存されるため、コンプライアンス監査を簡素化できます。
  • Amazon CloudWatch Logs との統合により、ログデータを検索したり、コンプライアンス違反のイベントを特定したり、インシデントの調査と監査者の要求に対する応答を迅速化したりできます。

ユーザーとリソースのアクティビティの可視化

  • AWS マネジメントコンソールでの操作と AWS API コールを記録することにより、ユーザーおよびリソースのアクティビティを把握しやすくなります。
  • AWS を呼び出したユーザーとアカウント、呼び出し元 IP アドレス、および呼び出し日時を特定できます。

セキュリティのオートメーション

  • セキュリティの脆弱性を引き起こす可能性のあるイベントが検出されたときに実行されるワークフローを定義できます。
  • 例えば、 Amazon S3 バケットを公開する API コールが CloudTrail によってログに記録されたときに特定のポリシーをそのバケットに追加する、というワークフローを作成できます。

利用してみる

  • CloudTrailにアクセスするとすでにログが記録されているのがわかります
  • 誰が何時に何の操作をしたのかがわかります

Screen Shot 2017-09-16 at 21.28.41.png

  • すべてのイベントを表示してみると

Screen Shot 2017-09-16 at 21.28.56.png

  • 7日以上のログを保存する場合や、アラートを飛ばしたいときは「証跡情報を作成」します

Screen Shot 2017-09-16 at 21.29.17.png

  • s3バケットなどを細かく設定できます!!!!!!

料金

  • WS CloudTrail を使用すると、サポートされたサービスの作成、変更、削除のオペレーションに関する過去 7 日間分のアカウントアクティビティの表示とダウンロードを無料で実行できます。

  • 証跡情報を作成する際に AWS CloudTrail からの課金は発生しません。CloudTrail の証跡を作成すると、Amazon S3 バケットに 2 種類のイベントを送信できるようになります。

  • 詳しくは公式の料金表

サポートされているサービス

ほとんどサポートされていますね

  • AWS Marketplace
  • Amazon Athena
  • Amazon CloudSearch
  • Amazon EMR
  • AWS Data Pipeline
  • Amazon Kinesis Firehose
  • Amazon Kinesis Streams
  • Amazon QuickSight
  • Amazon API Gateway
  • Amazon Elastic Transcoder
  • Amazon Elasticsearch Service
  • Amazon Simple Workflow Service
  • AWS Step Functions
  • Amazon Machine Learning
  • Amazon Polly
  • Amazon WorkDocs
  • アプリケーションの Auto Scaling
  • Auto Scaling
  • Amazon EC2 Container Registry
  • Amazon EC2 Container Service
  • AWS Elastic Beanstalk
  • Amazon Elastic Compute Cloud
  • Elastic Load Balancing
  • AWS Lambda
  • Amazon Lightsail
  • Amazon DynamoDB
  • Amazon ElastiCache
  • Amazon Redshift
  • Amazon Relational Database Service
  • Amazon WorkSpaces
  • AWS CodeBuild
  • AWS CodeCommit
  • AWS CodeDeploy
  • AWS CodePipeline
  • AWS CodeStar
  • Amazon GameLift
  • AWS IoT
  • AWS Application Discovery Service
  • AWS CloudFormation
  • AWS CloudTrail
  • Amazon CloudWatch
  • Amazon CloudWatch Events
  • Amazon CloudWatch Logs
  • AWS Config
  • AWS マネージドサービス
  • AWS OpsWorks
  • AWS OpsWorks for Chef Automate
  • AWS Organizations
  • AWS Service Catalog
  • Amazon Simple Email Service
  • Amazon Simple Notification Service
  • Amazon Simple Queue Service
  • AWS Database Migration Service
  • AWS Server Migration Service
  • Amazon Cognito
  • AWS Device Farm
  • Amazon CloudFront
  • AWS Direct Connect
  • Amazon Route 53
  • Amazon Virtual Private Cloud
  • AWS Certificate Manager
  • Amazon Cloud Directory
  • AWS CloudHSM
  • AWS Directory Service
  • AWS Identity and Access Management
  • Amazon Inspector
  • AWS Key Management Service
  • AWS Security Token Service
  • AWS WAF
  • Amazon Elastic Block Store
  • Amazon Elastic File System
  • Amazon Glacier
  • Amazon Simple Storage Service
  • AWS Storage Gateway
  • AWS Personal Health Dashboard
  • AWS サポート

サポートされていないもの

サポートされていないものもありますので注意が必要です。

Amazon AppStream
Amazon AppStream 2.0
Amazon Connect
Amazon Lex
Amazon Mobile Analytics
Amazon Pinpoint
Amazon Rekognition
Amazon WorkMail
AWS Batch
AWS Greengrass
AWS Shield
AWS Snowball
AWS X-Ray
Amazon Chime
Amazon WorkSpaces Application Manager
AWS Artifact
AWS Mobile Hub
AWS Snowball Edge
AWS Snowmobile
AWS Trusted Advisor

便利なリンク先

こちらいろいろやっていらっしゃる方がいます

まとめ

  • これでアカウントのガバナンス、コンプライアンス、運用監査、リスク監査を可能になりました。
  • 案外かんたんなので、設定触ってみることをおすすめします!

続きを読む

忙しい人のための Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities メモ

こんにちは、ひろかずです。

2017年7月に「Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities」が公開されました。
日本語翻訳されていないので、なかなか読めていない方もいると思います。
リリースから少し時間が経ってしまいましたが、読了したので一筆書きます。

どんなドキュメントか

OWASP Top10 で上っている各項目についての解説と、各項目についてAWS WAFでどのような対応ができるかを記載したもの。
Conditionを作る上でのアドバイスも記載されている。

参照ドキュメント

Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities

A1 – Injection

SQLインジェクション攻撃は、比較的簡単に検出できるが、バックエンドの構造によって複雑さが変わるため、アプリケーション側での対応も必要。
cookieやカスタムヘッダをデータベース参照に使う場合は、Conditionで検査対象とするように設定すること。
リクエスト中にクエリを流す事を是としているサービスの場合、対象URLを検知除外(バイパス)するような設定を検討すること。

A2 – Broken Authentication and Session Management

String Matchを活用して、盗まれた(怪しい)トークンを「安全のために」ブラックリストに登録する
デバイスのロケーションが異なるトークンを検出する等、ログから悪性利用をしているトークンを分析して、ブラックリストに登録するような使い方。
Rate-basedルールを用いて、認証URLを総当り攻撃を防ぐ施策も有効。

A3 – Cross-Site Scripting (XSS)

XSS攻撃は、HTTPリクエストで特定のキーHTMLタグ名を必要とするため、一般的なシナリオで比較的簡単に軽減できる。
BODYやQUERY_STRING, HEADER: Cookieを検査するのが推奨される。
URLを検査対象とすることは一般的ではないが、アプリケーションが短縮URL使っていると、パラメータはURLパスセグメントの一部として表示され、クエリ文字列には表示されない(後でサーバー側で書き換えられる)
CMSエディタ等、たくさんHTMLを生成するサービスには効果は薄い。
対象URLを検知除外(バイパス)する場合は、別途対策を検討すること。
加えて、<script>タグを多用するイメージ(svgグラフィックフォーマット)やカスタムデータも誤検知率が高いので調整が必要。

A4 – Broken Access Control

2017年から新たに登場
認証ユーザーの制限が適切に動作せず、必要以上に内部アプリケーションオブジェクト(不正なデータの公開、内部Webアプリケーション状態の操作、パストラバーサル、リモート/ローカルファイルの呼び出し)を操作できるというもの。
機能レベルのアクセス制御の欠陥は、一般的に後で追加されたアプリケーションで発生する。
アクセスレベルは、呼び出し時に一度検証されるが、その後に呼び出される様々なサブルーチンについては、都度検証されない。
呼び出し元のコードが、ユーザーの代わりに他のモジュールやコンポーネントを呼び出す暗黙的な信頼ができてしまう。
アプリケーションが、アクセスレベルやサブスクリプションレベルに応じてコンポーネントへアクセスさせる場合は、呼び出しの都度、検証する必要がある。

AWS WAFとしては、「../」や「://」をQUERY_STRINGやURIに含むかを検証することで、リモート/ローカルファイルの呼び出しを検出できる。
これも、リクエスト中に「../」や「://」を含む事を是とするアプリケーションには効果は薄い。
管理モジュール、コンポーネント、プラグイン、または関数へのアクセスが既知の特権ユーザーのセットに限定されている場合、Byte_MatchとIPSetの組み合わせでアクセスを制限することができる。

認証要求がHTTPリクエストの一部として送信され、JWTトークン(のようなもの)でカプセル化されている場合

  • Lambda@Edgeファンクションを用いて、関連リクエストパラメータがトークン内のアサーションおよび承認と一致することを確認することで、権限不適合リクエストはバックエンドに届く前に拒否することができる。

A5 – Security Misconfiguration

セキュリティの影響を受けるパラメータの設定ミスは、アプリケーションだけではなく、OSやミドルウェア、フレームワーク全てにおいて発生し得る。
セキュリティの影響を受けるパラメータの設定ミス例

  • ApacheのServerTokens Full(デフォルト)構成
  • 本番Webサーバーでデフォルトのディレクトリ一覧を有効にしたまま
  • エラーのスタックトレースをユーザーに戻すアプリケーション
  • PHPの脆弱なバージョンと組み合わせて、HTTPリクエストを介して内部サーバ変数を上書き

AWS WAFとしては、パラメータの設定ミスを悪用するHTTPリクエストパターンが認識可能な場合に限り対応可能。

  • A4 – Broken Access Controlと同様に、特定パスやコンポーネントに対してByte_MatchとIPSetの組み合わせでアクセスを制限を行う。(Wordpress管理画面 等)
  • 脆弱なPHPを利用している場合、QUERY_STRING中の“_SERVER[“を遮断する。

その他に考慮できること

  • Amazon Inspectorでの設定ミスの捜査(rootログイン許可や脆弱なミドルウェアバージョン、脆弱性の対応状況)
  • Amazon InspectorでのCISベンチマークとの適合性チェック
  • AWS ConfigやAmazon EC2 Systems Managerを用いた、システム構成変更の検出

A6 – Sensitive Data Exposure

アプリケーションの欠陥による機密情報の暴露をWAFで緩和するのは難しい。
この欠陥には、一般に不完全に実装された暗号化が含まれる(弱い暗号の利用を許容していること)

AWS WAFとしては、HTTPリクエスト中の機密情報を識別するパターンをString-Match Conditionで検出することで、機密情報へのアクセスを検出することができる。(ホストするアプリケーションに対する深い知識が必要)
アプリケーションが、アップロードを許容する場合、Base64を示す文字列の一部を検出するString-Match Conditionが有効(BodyはBase64でエンコードされているから)
一般的ではない手法

その他に考慮できること

  • AWS内の機能を使って、接続ポイントにて、ELBで強い暗号化suiteを使用するように制限する
  • クラシックロードバランサの場合、事前定義・カスタムセキュリティポリシーで制御できる。
  • アプリケーションロードバランサの場合、事前定義セキュリティポリシーで制御できる。
  • Cloud Frontでも利用するSSLプロトコルを制限できる。

A7 – Insufficient Attack Protection

2017年から新設
このカテゴリは、新しく発見された攻撃経路や異常なリクエストパターン、または発見されたアプリケーションの欠陥にタイムリーに対応する能力に重点を置いている。
幅広い攻撃ベクトルが含まれるので、他のカテゴリと重複する部分もある。

確認ポイント

  • アプリケーションに対して、異常なリクエストパターンや大量通信を検出できるか?
  • その検出を自動化できる仕組みはあるか?
  • 不要な通信に対して、ブロックできる仕組みはあるか?
  • 悪意のあるユーザーの攻撃開始を検出できるか?
  • アプリケーションの脆弱性に対するパッチ適用までの時間はどの程度かかる?
  • パッチ適用後の有効性を確認する仕組みはあるか?

AWS WAFで何ができるか

  • Size-Content Conditionを使うことで、アプリケーションで利用するサイズ以上の通信を検出・遮断できる。
  • URIやクエリ文字列のサイズを、アプリケーションにとって意味のある値に制限すること。
  • RESTful API用のAPIキーなどの特定のヘッダーが必要になるようにすることもできる。
  • 特定IPアドレスからの5分間隔での要求レートに対する閾値設定。(例えば、UserAgentとの組み合わせでのカウントも可能)
  • Web ACLはプログラマブルで反映が早いのが利点(CloudFrontに対しても約1分で反映)
  • ログの出力傾向から分析して、Web ACLを自動調整する機能も構築できる。

AWS WAFのセキュリティオートメーション機能の活用

  • Lambdaを使って、4xxエラーを多く出しているIPアドレスを特定してIPブラックリストに登録する。
  • 既知の攻撃者に対しては、外部ソースのIPブラックリストを活用する。
  • ボットとスクレイバに対しては、robots.txtファイルの ‘disallow’セクションにリストされている特定URLへのアクセスを行ったIPを、IPブラックリストに登録する。(ハニーポットと表現されています)

A8 – Cross-Site Request Forgery

CSRFは、WebアプリケーションのStateを変更する機能を対象としている。
State変更に係るURLやフォーム送信などのHTTPリクエストを考慮する。
「ユーザーがその行動を取っている」ということを必ず証明する機構がなければ、悪意のあるユーザーによるリクエスト偽造を判断する方法はない。

  • セッショントークンや送信元IPは偽造できるので、クライアント側の属性に頼るのは有効ではない。
  • CSRFは、特定のアクションのすべての詳細が予測可能であるという事実(フォームフィールド、クエリ文字列パラメータ)を利用する。
  • 攻撃は、クロスサイトスクリプティングやファイルインクルージョンなどの他の脆弱性を利用する方法で実行される。

CSRF攻撃への対処

  • アクションをトリガーするHTTPリクエストに予測困難なトークンを含める
  • ユーザー認証プロンプトの要求
  • アクション要求時のキャプチャの提示

AWS WAFで何ができるか

  • 固有トークンの存在確認
  • 例えば、UUIDv4を活用して、x-csrf-tokenという名前のカスタムHTTPヘッダーの値を期待する場合は、Byte-Size Conditionが使える。
  • ブロックルールには、POST HTTPリクエスト条件に加える

その他にできること

  • 上記のようなルールでは、古い/無効な/盗まれた トークンの検出については、アプリケーションでの対応が必要
  • 例えばの仕組み
  • サーバが、一意のトークンを隠しフィールドとしてブラウザに送信し、ユーザーのフォーム送信時の期待値にする。
  • 期待したトークンが含まれないPOSTリクエストを安全に破棄できる。
  • 処理後のセッションストアからトークンは削除しておくことで、再利用がされないことを保証。

A9 – Using Components with Known Vulnerabilities

既知の脆弱性を持つコンポーネントの利用
ソースや、商用/オープンソースのコンポーネント、フレームワークを最新に保つことが重要
最も簡単な攻撃ベクトルで、その他の攻撃手法の突破口にもなる。
脆弱なサブコンポーネントに依存するコンポーネントの利用しているケース。
コンポーネントの脆弱性は、CVEにて管理/追跡されないので、緩和が難しい。

  • アプリケーション開発者は、それぞれのベンダー、作成者、またはプロバイダとのコンポーネントのステータスを個別に追跡する責任を負う。
  • 脆弱性は、既存のバージョンを修正するのではなく、新機能を含む新しいバージョンのコンポーネントで解決される。
  • そのため、アプリケーション開発者は、新バージョンの実装、テスト、デプロイの工数を負担する。

基本的な対処に

  • アプリケーションの依存関係と基礎となるコンポーネントの依存関係の識別と追跡
  • コンポーネントのセキュリティを追跡するための監視プロセス
  • コンポーネントのパッチやリリース頻度、許容されるライセンスモデルを考慮したソフトウェア開発プロセスとポリシーの確立
  • これらにより、コンポーネントプロバイダーがコード内の脆弱性に対処する際に、迅速に対応できる。

AWS WAFで何ができるか

  • アプリケーションで使用していないコンポーネントの機能に対するHTTPリクエストをフィルタリングおよびブロックによる、攻撃面の削減
  • 例)HTTPリクエストを直接/間接的にアセンブルするコードへのアクセスのブロックする
  • String-matchコンディションを用いたURI検査(例えば、”/includes/”の制限)
  • アプリケーションでサードパーティのコンポーネントを使用しているが機能のサブセットのみを使用する場合は、同様のAWS WAF条件を使って、使用しないコンポーネントの機能への公開URLパスをブロックする。

その他にできること

  • ペネトレーションテスト。マーケットプレイスで買える。申請が必要だが、一部事前承認を受けているサービスでは申請が不要なこともある。(マーケットプレイス上のマークで識別可能)
  • 展開とテストのプロセスに統合して、潜在的な脆弱性を検出するとともに、展開されたパッチが対象となるアプリケーションの問題を適切に緩和する。

A10 – Underprotected APIs

2017年版の新カテゴリ
特定アプリケーションの欠陥パターンではなく、潜在的な攻撃ターゲットを示す

  • UIを持たないアプリケーションは増えてきている。(UI/API両方使えるサービスも同様)
  • 攻撃ベクトルは、A1-A9までと変わらないことが多い。
  • APIはプログラムからのアクセスのために設計されているので、セキュリティテストでは、追加の考慮事項がある。
  • APIは、(Rest,SOAP問わず)複雑なデータ構造での動作とより広い範囲の要求頻度と入力値を使用するように設計される事が多い。

AWS WAFでできること

  • A1-A9での対応と変わらないが、対APIとして追加でできる事がある。
  • 強化が必要な主要コンポーネントは、プロトコルパーサ自体(XML,YAML,JSON 等)
  • パーサーの欠陥を悪用しようとする特定の入力パターンをString-match Condition、またはByte-Size Conditionを使用して、そのような要求パターンをブロックする。

旧OWASP Top10 A10 – Unvalidated Redirects and Forwards

リダイレクトや転送要求を検証しない場合、悪意のある当事者が正当なドメインを使用してユーザーを不要な宛先に誘導する可能性がある。

  • 例)短縮URLを生成する機能がある場合、URLジェネレータがターゲットドメインを検証しないことで、悪意を持ったユーザーが正式サービス上から悪意のあるサイトへの短縮URLを発行できる。

AWS WAFでできること

  • まず、アプリケーションでリダイレクトとフォワードがどこで発生するのかを理解する(リクエストパターン等)
  • アプリケーションが使用する、サードパーティコンポーネントも同様にチェックする。
  • エンドユーザからのHTTPリクエストに応じてリダイレクトと転送が生成された場合は、AWS WAFでリクエストをQUERY_STRINGやURIに対するString-Match Conditionでフィルタリングする(リダイレクト/転送の目的で信頼されているドメインのホワイトリストを維持する)

Cloud Formationテンプレート

Web ACLと、このドキュメントで推奨されている条件タイプとルールを含むAWS CloudFormationテンプレートが用意されています。
今回は、解説を割愛します。

所感

AWS WAFの設定は基本的にDIYですが、実装のポイントをOWASP Top10になぞらえて、その対応を解説する良いヒント集だと思いました。
AWS WAFを設定する人は、一読するのがいいですね。
外部にAWS WAFの設定を依頼する人は、アプリケーションの特性をよく理解している人を立てて、設定する人とよくコミュニケーションを取ることが重要だとわかります。
セキュリティ製品の真価を発揮するには、保護する対象のサービスへの理解とサービスへの適合化が必要なのは、どんなソリューションにも共通しますね。

今日はここまでです。
お疲れ様でした。

続きを読む

Amazon Inspectorを使ってみたメモ

Amazon Inspectorを使ってみた

業務で脆弱性診断ツールの選定を任されたので、実際に使ってみた
(使ってみないと何がいいのかわからんよね)

サマリ

  1. IAMロール作成
  2. EC2インスタンスへのタグつけ
  3. AWSエージェントをインストール
  4. 評価ターゲットの定義
  5. 評価テンプレートの定義
  6. 評価の実行

IAMロールを作成

Amazon InspectorがAWS EC2インスタンスのタグ情報を取得できる必要があるため、
下記権限で作成する

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

EC2インスタンスへのタグつけ

EC2インスタンスに対して適当なタグをつける

AWSエージェントをインストール

脆弱性診断対象のEC2インスタンスに対してSSHし、エージェントをインストールする

[ec2-user@ip-10-0-1-41 ~]$ sudo su -
Last login: Wed Aug  2 22:31:53 JST 2017 on pts/0
[root@ip-10-0-1-41 ~]# cd /usr/src/
[root@ip-10-0-1-41 src]# wget https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
:
:
install                                            100%[================================================================================================================>]  26.60K  --.-KB/s    in 0s      

2017-08-12 15:40:42 (269 MB/s) - ‘install’ saved [27238/27238]

[root@ip-10-0-1-41 src]# 
[root@ip-10-0-1-41 src]# bash install -u false
Forced update specified as argument is : false
Distribution of the machine is Amazon Linux AMI.
Distribution type of the machine is amzn.
:
:
Current running agent reports version as: 1.0.1041.1
This install script was created to install agent version:1.0.1041.1
In most cases, these version numbers should be the same.
[root@ip-10-0-1-41 src]# 

評価ターゲットの定義

ここで、
1. どのインスタンスに対して診断をするのか(複数可)
2. 対象インスタンスのまとまりに対して名前つけ
を実施する
今回はこんな感じにしてみた
image.png

評価テンプレートの定義

何をもってして評価するのかをここで定義する。具体的には、
1. 評価基準(ルールテンプレートなるもの)
2. 診断時間(15分〜24時間)
3. 上記設定をした評価基準に対しての名前つけ
を実施する。今回はこんな感じにしてみた
image.png

評価の実行

1〜5までの設定が全て完了したら最後は実行するのみ!
image.png
※すでに実行後なため実行ボタンが選択できなくなっています。。。

結果などがでてきたらまた続きをかきたいと思います!

続きを読む

Amazon Inspectorを試してみた

Amazon Inspectorとは

EC2で実行されているアプリケーションのセキュリティ状態をテストできるものです。

利用可能なリージョン

us-east-1,us-west-2,eu-west-1,ap-northeast-1

利用可能なOS

Amazon Inspector でサポートされているオペレーティングシステムとリージョン

Amazon Linux (2015.03、2015.09、2016.03、2016.09、2017.03)
Ubuntu (14.04 LTS、16.04 LTS)
Red Hat Enterprise Linux (6.2、6.3、6.4、6.5、6.6、6.7、6.8、6.9、7.2、7.3)
CentOS (6.2、6.3、6.4、6.5、6.6、6.7、6.8、6.9、7.2、7.3)

設定

EC2にエージェントインストール

今回はAmazon Linuxで試しました。

$ cat /etc/system-release
Amazon Linux AMI release 2017.03

ダウンロードしてインストールします。
リンクの手順に沿ってやるだけです:point_up::dizzy:
AWS エージェントをインストールするには

$ wget https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install

$ sudo bash install

Inspectorの設定

  1. サービスから「Inspector」を選択
  2. 左ペインから「評価ターゲット」を選択し、「作成」をクリック
  3. 名前とキーを入力して「保存」
    スクリーンショット 2017-08-01 10.13.44.png

  4. EC2にタグ付けする
    スクリーンショット 2017-08-01 13.16.58.png

  5. Inspectorで先ほど作成した評価ターゲットの左にある矢印をクリックして、「プレビュー」をクリックするとタグ付けされたEC2が出力されます
    スクリーンショット 2017-08-01 13.19.39.png
    →これが評価ターゲットになります。

  6. 左ペインから「評価テンプレート」をクリックして「作成」をクリックします。

  7. ターゲット名は先ほど作成した評価ターゲットを選択します。
    ルールパッケージは以下から選択可能です。今回はCVEを選択してみました。
    Amazon Inspector のルール パッケージとルール
    ・ 共通脆弱性識別子(CVE)
    ・ Center for Internet Security (CIS) ベンチマーク
    ・ セキュリティのベストプラクティス
    ・ 実行時の動作の分析
    所要時間は長ければ長いほど、より精密な結果が得られるとのことです。
    AWS推奨は1時間。
    SNSと連携してメール飛ばせたりしますが、ここでは省略。
    「作成および実行」を押すと調査が始まります。

スクリーンショット 2017-08-01 13.34.48.png

結果

スクリーンショット 2017-08-01 13.47.29.png
指定した時間が経過すると、調査結果が出力されます。
重要度の左にある矢印をクリックすると詳細が確認で、CVEのページのリンクも載っています。

脆弱性が自分のインスタンスに影響しているのか否か判断できて便利ですね:baby:

料金

料金は月あたり 1 エージェント 1 評価あたり 0.30 USD から始まり、従量制割引により月あたり 1 エージェント 1 評価あたり 0.05 USD の低価格でご利用いただけます。

Amazon Inspector料金

Amazon Inspectorの価格体系について

評価実行中のインスタンスへの影響

評価実行プロセス中のパフォーマンスへの影響を最小限に抑えるように設計されています
Amazon Inspector のよくある質問

CloudWatchで確認してみましたが、CPU使用率が高騰することはありません(上がっても1%未満)でした。

関連資料

BlackBelt

Amazon Inspector とは

Amazon Inspector のよくある質問

続きを読む

Amazon Inspectorのレポート機能を試す

こんにちは、ひろかずです。
Preview版の時にAmazon Inspectorの評価を行いましたが、それっきりになってしまいました。
Amazon Web Services ブログでレポート機能が追加されるなどのアップデートがなされたので、一筆書きます。

目的とゴール

GA/アップデート後のAmazon Inspectorを実行し、その差分とレポート機能がどんなものかを確認する。

参考ドキュメント

Amazon Inspectorユーザーガイド

お品書き

  • 仕様
  • インストール手順
  • 実行手順
  • レポート機能

仕様

対応環境とルールパッケージ

Windows対応やRHEL6系への対応は聞いていましたが、新たにRHEL7.3系に対応されていました。
日本語ドキュメントでは、RHEL7.2系までの記載でしたので、英語ドキュメントを確認するように心がけたいですね。

対応環境毎に利用できるルールパッケージが異なるので、スキャンを実施する前に確認してください。
サポートされているオペレーティングシステムに関して、提供されているルールパッケージ

ルールパッケージは、Preview版は6種類でしたが、現在は4種類にスリム化されています。

  • 共通脆弱性識別子
  • Center for Internet Security (CIS) ベンチマーク
  • セキュリティのベストプラクティス
  • 実行時の動作の分析

課金体系

課金体系として、エージェント評価という聞きなれない単語が使われていますね。
Amazon Inspector 料金
ちょっとわかりにくいですが、エージェント数 x 評価回数を示すようです。
FAQ:Q: Amazon Inspector の料金体系について教えてください。を見るとイメージし易いかもしれません。

ボリュームディスカウントにも言及されているので、たくさん利用する人は要チェックですね。

インストール手順

基本的な手順はPreview版とさほど変わりがありませんでした。
手順は、過去記事を参考にしてください。

実行手順

基本的な手順はPreview版とさほど変わりがありませんでした。
手順は、過去記事を参考にしてください。

ルールパッケージは選択可能な4種類を全て選択しました。
Inspector6.png

レポート機能

レポートの出力

スキャンが完了すると、レポートアイコンが表示されました。
Inspector8.png

クリックするとFinding ReportFull Reportが出力できるようです。
Inspector9.png

内容

全編英語です。
目次がないので、見出しを拾うと以下のようになっていました。
RHEL7.3環境で実行したので、対応していないCISベンチマークは掲載されていません。

Section 1: Executive Summary

ルールパッケージ毎の検知件数が記載されています。
report1.png

Section 2: What is Tested

利用されたルールパッケージの説明が記載されています。
スキャンした対象(Assessment Target)の条件設定が記載されています。
report2.png

report21.png

Section 3: Findings Summary

各ルールパッケージで検出された項目と緊急度が記載されています。
AWSコンソールでページ送りする必要がないのがいいですね。
report3.png
report31.png

Section 4: Findings Details

各ルールパッケージで検出された項目の対応方法が記載されています。
記載内容はAWSコンソールで表示されている内容と同じですが、一つ一つ開かなくて良いので見やすいかもしれません。
report4.png

Section 5: Passed Rules

Full Reportのみのセクションです。
クリアしたルールパッケージの内訳が全て掲載されています。
Amazon Inspectorは全てのCVEに対応している訳ではないので、検査時にチェックされたCVEを確認する上では有用でしょう。
report5.png

おわりに

脆弱性の対応状況を見える化することは、安全な運用の第一歩です。
今回のアップデートで、AWSコンソールを見なくても結果が分かるようになったのは良かったと思います。

一方で、以前検証した際に懸念した、継続的な脆弱性のハンドリングについては、課題を残したままのように思えます。
判断の履歴や対応しない(必要がないと判断された)脆弱性の管理をどのように行うかがカギだと言えるでしょう。

今日はここまでです。
お疲れ様でした。

続きを読む

AWS 認定ソリューションアーキテクト – アソシエイト 合格までに勉強したこと

概要

AWS 認定試験には「これを勉強すればいいよ!」という教科書があるわけではないので、何を勉強したらいいか分からず困っている人も多いと思います。
なので、私の勉強記録を共有します。

勉強前のスペック

AWSの初級者です。
EC2インスタンス起動やEBSのスナップショット取得の経験があるくらいでした。

勉強方法概要

AWS活用本を一冊読んで、
あとはAWS クラウドサービス活用資料集にある BlackBelt のスライド(PDF)を淡々と読みました。

その後、模擬試験を受けて本試験を受験しました。

勉強方法詳細

少し前に買っていた以下の本を読みました。分かりやすいです。

Amazon Web Services 定番業務システム12パターン設計ガイド

BlackBelt

自分が読んだ資料に○を付けました。
また、模擬試験と本試験を受けた経験から、各資料の重要度を評価しました。
※当たり前ですが、読んでいない資料の重要度は評価していません。また、重要度の正確性も保証しません。

コンピューティング

資料 読んだ  重要度 
[Amazon EC2] 
[Amazon EC2] Windows
[Amazon EC2] HPC
[Amazon EC2] リザーブドインスタンス
[Amazon EC2] スポットインスタンス
[Amazon EC2] Instance Store & Elastic Block Store
[Amazon EC2] VMImport/Export
[Elastic Load Balancing]
[Elastic Load Balancing] ロードバランサと Socket 接続を使用したイベント通知サーバの負荷分散
[Elastic Load Balancing] ELBを評価するためのベストプラクティス
[Auto Scaling]
[Amazon EC2 Container Service]
[AWS Elastic Beanstalk]
[AWS Lambda]
[AWS Lambda] update
[Amazon Lightsail]
[AWS Batch]

ストレージ & コンテンツ配信

資料 読んだ  重要度 
[Amazon EBS]
[Amazon S3] 
[Amazon CloudFront]
[Amazon CloudFront] Flash Media Server on AWS
[Amazon CloudFront] CloudFront 上限緩和申請 計算方法&申請手順
[Amazon CloudFront] まだ間に合う! Amazon CloudFront で ATS 対応
[Amazon Glacier]
[Amazon Glacier] 機能編
[AWS Storage Gateway]
[Amazon Elastic File System]

データベース

資料 読んだ  重要度 
[Amazon RDS]
[Amazon RDS] Aurora
[Amazon DynamoDB]
[Amazon ElastiCache]
[Amazon ElastiCache] Redis QA資料
[Amazon Redshift] 
[Amazon Database Migration Service]

ネットワーキング

資料 読んだ  重要度 
[Amazon VPC]
[Amazon VPC] VPN接続設定 参考資料
[AWS Direct Connect] 
[Amazon Route53]

開発者用ツール

資料 読んだ  重要度 
[AWS CodeCommit]
[AWS CodeBuild]
[AWS CodeDeploy]
[AWS CodePipeline]
[AWS SDK]
[AWS SDK] Java & .NET
[AWS SDK] PHP & Ruby & Boto(Python) & Javascript in Node.js
[AWS SDK] AWS Client side SDK Android & iOS & Javascript
[AWS CLI]
[AWS AWS Tools for Windows Powershell]

管理ツール

資料 読んだ  重要度 
[Amazon CloudWatch]
[AWS CloudFormation]
[AWS CloudTrail]
[AWS Config]
[AWS OpsWorks] AWS OpsWorksのご紹介
[AWS OpsWorks]
[AWS OpsWorks] ハンズオン
[AWS Service Catalog]
[Trusted Advisor] AWS サポート & Trusted Advisor
[Amazon EC2 Systems Manager]

セキュリティ & アイデンティ

資料 読んだ  重要度 
[Identity and Access Management (IAM)] 
[AWS CloudHSM] CloudHSM & Key Management Service
[AWS Key Management Service]
[AWS Directory Service]
[Amazon Inspector]
[AWS WAF]
[AWS Certificate Manager]

分析

資料 読んだ  重要度 
[Amazon EMR(Elastic MapReduce)]
[AWS Data Pipeline]
[Amazon Elasticsearch Service] Amazon CloudSearch & Amazon Elasticsearch Service
[Amazon Kinesis]
[Amazon QuickSight]
[Amazon Athena]

AI

資料 読んだ  重要度 
[Amazon AI]]

IoT

資料 読んだ  重要度 
[AWS IoT]

ゲーム開発

資料 読んだ  重要度 
[Amazon Lumberyard]

モバイルサービス

資料 読んだ  重要度 
[Amazon Cognito]
[Amazon Cognito] Amazon Cognito update
[Amazon Cognito] Amazon Cognito / Amazon Mobile Analytics
[AWS Device Farm]
[Amazon Mobile Analytics] Amazon Cognito / Amazon Mobile Analytics
[Amazon SNS] Amazon SNS/SQS
[Amazon SNS] モバイルプッシュ通知
[Amazon Pinpoint]  

アプリケーションサービス

資料 読んだ  重要度 
[Amazon API Gateway] 
[Amazon AppStream]
[Amazon CloudSearch] Amazon CloudSearch & Amazon Elasticsearch Service
[Amazon Elastic Transcoder]
[Amazon SES]
[Amazon SES] Amazon SES-Easy DKIM 設定サポート資料
[Amazon SQS] Amazon SNS/SQS
[Amazon Simple Workflow Service (SWF)]

エンタープライズアプリケーション

資料 読んだ  重要度 
[Amazon WorkSpaces]
[Amazon WorkDocs]
[Amazon WorkMail]
[Amazon Chime]

その他

資料 読んだ  重要度 
[Cost Explorer]
[AWS Management Console]

補足

重要度の低い資料も読んだ方がいいです。
なぜなら、マネージドサービス自体がAWSの活用事例であり、それらを知ることでシステム設計の勘所が分かるようになるからです。
また、重要度の高い機能との連携についての記載があることもあり、理解が深まります。

続きを読む

AWS Summit Tokyo 2017 参加レポート Day3 (6/1)

会社の外部研修として『AWS Summit Tokyo 2017』に6月1日(木)~2日(金)の計2日間参加して来ました。

当エントリでは6月1日(Day3)に聴講した内容をレポートします。(Day4のレポートはこちら
※注)記事には個人的なメモや感想が含まれています。予めご承知ください。


基調講演(Key Note) (10:00 ~ 11:30)

ホストトーク:オープニング

by Werner Vogels 氏 (Amazon.com CTO)

  • AWSは急速に成長している

    • 成長率はIT企業の中でもTOP
    • 毎月のユーザー増加数 = 日本では10万以上
    • 各国のリージョン、AZ、エッジロケーションも随時拡大中
  • 本イベントを通してAWSを色々学んで行って欲しい。

気になったワードメモ

  • AWS Activate
  • One Amazon
  • Osaka リージョン開始

ゲストトーク:株式会社ソラコム

by 安川 健太 氏 (株式会社ソラコム 最高技術責任者)

SORACOMのサービス展開

IoTはネットワークセキュリティが課題
>3G/LTE網でInternetに出ないIoTネットワーク(デバイスとクラウドの直接接続)を提供

SORACOM Funnel
>デバイスからクラウドへのデータ転送を疎結合に管理
 利用例:デバイス>Funnel>Kinesis>Lambda>AWS IoT
  ⇒Funnelから先の切り替え(=新サービス追加など)が容易

ホストトーク:AWS – SUPER POWERS 1

by Werner Vogels 氏 (Amazon.com CTO)

「AWSは開発者に『SUPER POWERS※』を与える。」 (※ネタ元:スーパーマン)

SUPER POWER – ‘SPEED’ (超音速)

  • EC2新インスタンス:F1(FPGA利用可)
  • 今の時代 検索は必須>Elastic Search等ですぐに実装可
  • CloudはInfraへの関心を省き、Productに集中させてくれる>開発を加速
  • AWSは色々な選択肢を提供>ビジネスに合わせて適切なものを

ゲストトーク:NTT東日本

by 中村 浩 氏 (東日本電信電話株式会社 取締役)

CloudGateway re:connect
>FLETS光の高速・閉域網でAWSと再接続

社内で開発・利用して便利だったものを社外にも利用してほしい
クラウドと企業間の距離が一番近い国に

ホストトーク:AWS – SUPER POWERS 2

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘INVISIBILITY’ (目に見えない)

⇒開発者がインフラを気にしなくていい ⇒サーバーレス機能群紹介

  • AWS Lambda

    • サーバーレスコンピュート
  • AWS Step Functions
    • ビジュアルワークフローで分散アプリケーションのコンポーネント管理
  • AWS X-Ray
    • 分散アプリケーションの分析とデバッグ
  • Amazon DynamoDB Accelerator(DAX) :new:
    • 完全マネージド型インメモリキャッシュクラスタでクエリ超高速化

ゲストトーク:ソニーモバイルコミュニケーションズ

by 川西 泉 氏 (ソニーモバイルコミュニケーションズ株式会社 取締役 EVP)

SonyモバイルのIoTへの取り組み:『カーリングビジネスの実現』

製品紹介
– XPERIA Ear
– XPERIA Touch
– XPERIA Agent
  >http://av.watch.impress.co.jp/docs/news/1018278.html

スマートホームシステム
 AWS IoTを活用
 製品例:自宅のLED照明>センサーで子供の帰宅感知>仕事(外出)中の親に通知>LED付属のスピーカで会話

ホストトーク:AWS – SUPER POWERS 3

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘FLIGHT’ (飛び立つ)

IoTデバイスはサーバを必要としない

  • AWS Greengrass
     ⇒サーバ側の役目だった処理をローカルで構築可能に

これまでのデータベース=実機やベンダー由来の様々な制約や障害があった
クラウド+オープンソースのDBで”制約”から飛び立とう

  • AWS Database Migration Service
  • Amazon Aurora
    • 完全MySQL互換のRDB
    • PostgreSQL互換も提供開始

ゲストトーク:グリー株式会社

by 藤本 真樹 氏 (グリー株式会社 開発・人事統括 取締役 執行役員常務 CTO)

オンプレで10年運用してきた環境をクラウドへ移行した話

技術選択の判断は難しい、基準には色々な軸がある
敢えて上げるならば、”is that faster?”
>速さは裏切らない(コンピュータが速くて困ることは絶対にない)

⇒ AWS(の機能やサービス展開速度)はこれらに応えられる

ホストトーク:AWS – SUPER POWERS 4

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘X-RAY VISION’ (透視)

⇒ データの集計・可視化

  • Amazon Athena

    • S3に保存されたデータを標準SQLで簡単に分析
  • Amazon EMR
    • Hadoopなどのビッグデータフレームワークを手軽に実行・分析可能
  • Amazon Redshift
    • 複雑なクエリ・超高速パフォーマンスを提供するペタバイト級データウェアハウス
  • Amazon Redshift Spectrum :new:
    • S3のデータを直接クエリ可能
    • エクサバイト規模のクエリ>Hiveで5年想定の処理を155秒で完了

SUPER POWER – ‘PRECOGNITION’ (予見)

⇒ Amazon AI – 人工知能サービス

  • Amazon Machine Learning

    • カスタム予測モデルの学習
  • Amazon Rekognition
    • 画像から顔と感情を認識
  • Amazon Polly
    • 文章をリアルな音声に変換(感情付加など)
  • Amazon Lex
    • 自動音声認識・自然言語理解

SUPER POWER – ‘IMMORTALITY’ (不朽)

⇒ スタートアップ企業生き残りの鍵 =『デジタルトランスフォーメーション』

AWSは『イノベーション』を続ける


AWS 認定試験 (12:30 ~ 13:50)

Summit特設会場でソリューションアーキテクトアソシエイト試験を受験(特典の50%OFFクーポン目当てです ^^; )

試験終了後すぐに認定者限定ラウンジに行ってみましたが、ノベルティの折り畳み傘はとっくに品切れでした;;
やはり一日数量限定は午前中に行かないと無理な模様。( ⇒ Day4で無事GET!!)

限定ラウンジではお菓子や飲み物が無料、座ってPCなどの充電が出来て中々快適でした。
モニタなど設置して講演中のセッションを視聴できればいいなと考えましたが、逆に人が溢れて寛げなくなりそう?


Session:『AWS Shield と AWS Lambda@Edge で構築するセキュアで柔軟性の高いアプリケーション』 (14:20 ~ 15:00)

スピーカー:Prasad Kalyanaraman 氏 (Vice President, AWS Edge Services)

セッション概要(タイトルリンク先より引用)

AWS Edge Services では、Amazon CloudFront に加え、AWS Shield、 AWS Lambda@Edge などの革新的な新サービスを発表しています。本セッションでは、AWS Shield の DDoS 防御機能と、AWS Lambda@Edge の CDN 上でのスクリプト実行により、セキュリティを担保しつつ柔軟でカスタマイズ性の高いアプリケーションの実現方法をご紹介します。

エッジでのセキュリティ活用

セキュアコンテンツ配信にCloudFrontが使える
 >エンドユーザー付近をセキュア通信の終端にする

Lambda@Edge

=Lambda関数のデリバリーサービス
 ・Bot 判定
 ・バリデーション
 ・認証処理
  ⇒エンドユーザ付近で実行できる
 ・ユーザ毎にコンテンツカスタマイズ可能
  e.g.
   ・PC/モバイル判定>アクセス先分岐
   ・エッジでHSTSヘッダを埋込み

DDoS対策 (スクラビングセンター)

 >AWS Shield (全Edgeロケーションで使用可)
  >Standard
   ・エッジで攻撃を検知し、遮断
   ・リアルタイムで悪意のあるトラフィックを検出
   ・無料で自動適用
  >Advanced
   ・攻撃データの可視化、およびイベント後の分析と調査を容易に
   ・DDoS攻撃で請求金額が跳ね上がるのを防ぐ「DDoS コスト保護」
   ・専門サポート
   ・有料

AWS WAF

 >L7(アプリケーションレイヤー)防御
 >Lambdaで独自のセキュリティチェック可 (e.g. 特定のIPを一定時間ブロック等)


Session:『Amazon ECS と SpotFleet を活用した低コストでスケーラブルなジョブワーカーシステム』 (15:20 ~ 16:00)

スピーカー:松田 和樹 氏 (株式会社インティメート・マージャー 開発本部)

セッション概要(タイトルリンク先より引用)

インティメート・マージャーではビジネスの都合上、50 種類ものジョブワーカーを運用しております。増え続けるビジネス要件に対応するため、Amazon ECS と SpotFleet を軸に Amazon S3、Amazon SQS、Autoscaling を組み合わせることで、低コストかつスケーラブルな docker 基盤を構築致しました。本セッションでは、その docker 基盤を中心にお話しします。

公演に使用されたスライドが公開されてます。

構築背景

  • 20以上の社外システムとデータ受渡し

    • 異なるデータ形式
    • 異なる接続方式
  • データ肥大化
    • スケールする仕組みが必要
    • 特定のジョブのみスケールさせたい

第一世代

処理フロー

S3ファイルUP>イベントをSQS通知>Cloud Watchでキュー数監視>EC2のワーカーをAutoScaling (Spot)
 >SQSキュー&S3ファイルを取得し処理>後続処理は別のS3へ

課題

  • スポット高騰時など特定のワーカーが起動不可となる
  • リソース(InstanceType)効率が悪い
  • 待機時間が長い
  • スケーリング設定多く、運用負荷高い

第二世代

変更点

  • 全ワーカーの実行環境をコンテナに
  • docker基盤共用
  • ECS採用
  • spot fleet採用
  • ワーカー毎にコンテナをスケール

Amazon ECS

  • 52のサービスが稼働 ( 50種のワーカー + Mackerel(監視) + Fluentd(ログコレクタ) )
  • コンテナレジストリ ⇒ Amazon ECR

Spot fleet

  • 168 vCPU
  • 自動入札(一つ一つ設定も可能だが手間)
  • InstanceType:7種 主にC4、M4系

運用のポイント

ログのハンドリング

  • 目的で集約先使い分け

    • 常時監視 ⇒logdna
    • 長期分析 ⇒BigQuery
    • 直近データ分析、参照 ⇒Aurora

環境構築・デプロイ

  • Terraform採用
  • CircleCIからAPIでデプロイ
     ⇒docker対応CIサービスがおすすめ

強制ターミネート(Spotインスタンス)

  • コンテナ強制終了
  • 検知する仕組み必要
    • メタデータをポーリング⇒クラスタから退役

AMI

  • ECS-Optimized AMI 使用
  • AMIのカスタマイズはしない
  • 設定はcloud-initで

ECSの課題

  • クラスタ管理

    • agent方式⇒ラグが多々
    • ゾンビワーカー
  • docker全機能は使えない
  • コンソール画面がまだまだ
  • 学習コストそこそこ

ECSの強みは他AWSサービスとの連携


Session:『AWS で実現するセキュリティ・オートメーション』 (16:20 ~ 17:00)

スピーカー:桐山 隼人 氏 (AWSジャパン 技術統括本部 ソリューションアーキテクト)

セッション概要(タイトルリンク先より引用)

クラウドは、今までやってきたことを効率的にするだけでなく、今までできなかったことを可能にします。本セッションでは、セキュリティをクラウド環境で実現することで可能となる、運用統合と自動化(オートメーション)をご紹介します。セキュリティ・オートメーションは、貴社の運用が変わるだけでなく、セキュリティ戦略そのものを見直すきっかけにもなります。オートメーションによる次世代のセキュリティを考えてみませんか?

※スライドは公開されていないようですが、ほぼこれと同じだったかと思います。

クラウド移行に関するアンケート

日:クラウドに移行しない理由 1位 ⇒セキュリティ
米:クラウドに移行した理由 1位 ⇒セキュリティ
 ⇒まだ正確な認識が普及していないせいと思われる

クラウドだからできるセキュリティ

オートメーションとは=戦略策定の基盤
AWSはセキュリティオートメーション前提に設計されている ⇒基盤として活用してほしい

  • 戦略策定

    • SFA、マーケティングに活用
    • やること やらないこと を決められる
  • 何を自動化すべきか? (考える主軸 ⇒)

    • 対策主体(人、組織、技術)
    • 対策対象(サーバ、ネットワーク、クライアント)
    • 対策場所(入口、内部、出口)

ガートナーの『適応型セキュリティアーキテクチャ』

サイクルを回す:
 防御⇒検知⇒対応⇒予測⇒~

 防御:CloudFront、WAF ~
 検知:VPC Logs、Auto Scaling ~
 対応:SNS、Lambda ~
 予測:EC2 Config、3rd party レピュテーション、Inspector ~

実用例

CloudFrontアクセス⇒WAF⇒LambdaでレピュテーションリストDL&判定
 ⇒Lambdaでセキュリティ評価⇒Amazon Inspector⇒SNS⇒LambdaでNACL/SG変更
 ⇒攻撃検知⇒ブロックログ⇒EBSなどsnapshot⇒CloudTrail(操作ログ)
全レイヤー、ノードのログが取れるので
 ⇒VPC Flow Logs/Elastic Search/Kibanaなどで可視化
攻撃者のドメイン生成は自動化されている:Domain Generation Algorithm(DGA)
 ⇒AWS WAF + Amazon MLで怪しいドメインを学習
Machine Learningでリスク分析
 ⇒設定変更などの意思決定まで自動化


Session:『Machine Learning on AWS』 (17:20 ~ 18:00)

スピーカー:志村 誠 氏 (AWSジャパン 技術統括本部 ソリューションアーキテクト)

セッション概要(タイトルリンク先より引用)

AI や機械学習という言葉が話題になる遥か前から、Amazon では機械学習技術を活用したさまざまな取り組みを行ってきました。本セッションでは AWS の上でご利用いただける機械学習サービスについてご紹介するととともに、それらをどのように使い分けるか、また機械学習をどのように皆さまのサービスに役立てて行くかについてご紹介します。

どんなサービスで機械学習を活用するか?

ビジネス主体で考える(使いたい技術から考えない)

  • 良質なデータが継続的に入るか
  • 自動化の価値ある予測か
  • 費用対効果

機械学習はあくまでツール
需要に反し解決していない問題に対して検討する

代表的な活用例>
– レコメンド
– 異常検知
– 画像認識
– クラスタリング(ユーザの分類分けなど)

AWSで提供する機械学習サービス

グルーピング>

  • Service
  • platform
  • Engines
  • Hardware

AI Hardware

  • EC2:P2 instance

    • GPU特化
  • Greengrass
    • デバイスに学習モデル
    • エッジで推論処理

AI Engines

典型的な機械学習フレームワークをインストール済みのAMIを提供

AI platform

  • Amazon Machine Learning
  • Amazon EMR

AI Service

  • Polly
  • Rekognition
  • Lex

その他

Kinesis Analytics >異常検知
Elastic Search >検索を機械学習に利用
Data Pipeline >EMRのジョブをスケジューリング

ゴールを明確に

  • 解決すべき課題
  • アウトプット

続き⇒Day4

続きを読む