JNSA西日本支部技術研究WG AWSを使ったセキュアなシステム構築

クラウドで、世界を、もっと、はたらきやすく　　　　　　　　　　Copyright © Serverworks Co.,Ltd. All Rights Reserved. 　　　　　　　　　　　　 h9p://www.serverworks.co.jp
AWSを使ったセキュアなシステム構築
JNSA⻄⽇本⽀部技術研究WG 勉強会#1
⻄⽇本⽀部技術研究WG
株式会社サーバーワークス
久保智夫
2016/08/25

Page: 2 Copyright © Serverworks Co.,Ltd. All Rights Reserved.
久保智夫
株式会社サーバーワークス
クラウドインテグレーション部技術⼆課ソリューションアーキテクト
Tomo-o KUBO
AWS/SaaSを中⼼としたCloudIntegraJonに従事

【経歴】
•  株式会社インターネットイニシアティブ(IIJ)
•  NW中⼼にインフラ全般のSI/SaaS/CI
•  IPv6導⼊/セキュリティコンサル活動/インシデント
対応⽀援
•  株式会社MonotaRO
•  インフラ担当／社内情シス担当マネージャ
•  等を経て2015年より現職

Content Index
SECTION AWSの主要サービス1
IaaS案件の代表的構成
AWSを使ったシステム構築のサイクル
実践編
SECTION 2
SECTION 3
SECTION 4

Content Index
SECTION 1
SECTION 2
SECTION 3
SECTION 4
AWSの主要サービス
実践編

（簡単に）AWSの主要サービス
あまりにも数がありすぎるので、
今回は頻繁に利⽤するサービスに絞って解説します

いっぱいあります…
あまりにも数がありすぎるので、
今回は頻繁に利⽤するサービスに絞って解説します

インフラ関連サービス
Compute
EC2
(仮想サーバ)
ECS&ECR
(Docketコンテナ)
Elastic Load Balancing
(ロードバランサー)
Lambda
(イベント駆動型のコード実⾏)
Storage &
ContentDelivery
S3
(オブジェクトストレージ)
Glacier
(アーカイブストレージ)
EFS
(共有NFSストレージ)
等
Cloud Front
(CDN)
Database DMS
(DB移⾏)
RDS
(RDBMS)
DynamoDB
(KVS)
ElastiCache
(メモリキャッシュ)
RedShift
(データウェアハウス)
等
等
Networking VPC
(仮想プライベートクラウド)
Route53
(DNSホスティング)
Direct Connect
(専⽤線接続)

その他（管理・セキュリティ・分析他）
Management
Tools
Security &
Identity
Analytics &
IoT
CloudWatch
(監視・ログ)
CloudFormation
(テンプレート
構築ツール)
CloudTrail
(利⽤ログ監査)
CloudTrail
(リソース
変更管理)
TrustedAdvisor
(コスト・セキュ
リティ最適化)
IAM
(権限管理)
Directory Service
(ActiveDirectory)
Inspector
(セキュリティ評価)
KMS
(秘密鍵管理)
CloudHSM
(ハードウェア
セキュリティ
モジュール)
ACM
(証明書管理)
WAF
等
等
等
Elasticsearch
Service
(Elastic Search)
EMR
(MapReduce)
Kinesis
(ストリーム
データ処理)
Machine
Learning
(機械学習)
QuickSight
(BI)
IoT
Application
Services
API Gateway
(APIデプロイ)
AppStream
(リッチアプリ配信)
Elastic Transcoder
(動画トランスコード)
SES
(メール配信)
SQS
(メッセージキュー)
CloudSearch
(検索サービス)
等

エンタープライズ・アプリケーション
Enterprise
Applications
WorkDocs
(エンタープライズ
ストレージ)
WorkMail
(企業向け
Eメール＆カレンダー)
WorkSpaces
(仮想デスクトップ)
他にもモバイル系サービスやコード管理等様々
な種類のサービスが存在
（個⼈的にはまだあまりお⽬に掛からない）

Content Index
SECTION 1
SECTION 2
SECTION 3
SECTION 4
実践編

Page: ‹#› CONFIDENTIAL Copyright © Serverworks Co.,Ltd. All Rights Reserved. Page: 11 Copyright © Serverworks Co.,Ltd. All Rights Reserved.
IaaS案件の代表的な構成
IaaS案件に多い要件(1)
• Web + AP + DBサーバから成る三層アーキテクチャを中⼼としたシス
テム
• オンプレミス（物理／仮想）で動かしているアプリケーションをそっく
りそのまま移⾏する“Lift and Shift”
システムアーキテクチャ
• クラウド側にプライベート空間を作り、仮想サーバやDBMSを配置
• 既存のWANやLANとプライベート接続（社内アドレス空間の延⻑）
ネットワーク
• 各サーバは冗⻑化（負荷分散＆耐障害性向上）
• データセンターレベルで分散配置し拠点災害時のサービス継続に配慮
可⽤性・信頼性

IaaS案件に多い要件(2)
•  Web／APサーバは⽇次バックアップ
•  DBサーバはPoint-in-Time-Recoveryが可能なバックアップ
バックアップ
•  ⾃社運⽤ or 運⽤アウトソース（24h/365d）
•  プロセス／ログ／URL／リソース・・・等の監視
運⽤監視
•  公開サーバはWAF／IPS／改ざん検知／マルウェア検知等
•  ⾮公開サーバはホスト側IPS／マルウェア検知等
セキュリティ

  Web + AP + DBサーバから成る三層アーキテクチャ
  VPCでプライベート空間を作り、仮想サーバ(EC2)やDBMS(RDS) を配置
  各サーバは冗⻑化、データセンターレベルで分散配置し災害時のサービス継続に配慮
  その他、要件に応じてセキュリティソリューションの導⼊(WAF/IPS/NGFW等)
  バックアップはAWSの標準機能（EC2->スナップショット）で5世代管理
  既存WAN／LANとはVPNやDirectConnectでプライベート接続
セキュリティ要件以外を取り⼊れたシステム
AWS cloud
virtual private cloud
Availability Zone A Availability Zone B
Web/AP Web/AP
DB(Master) DB(Slave)
LB
Internet Gateway
on-premise data center

使⽤したサービスコンポーネント
Compute
EC2
(仮想サーバ)
Elastic Load Balancing
(ロードバランサー)
Storage &
ContentDelivery
S3
(オブジェクトストレージ)
Database
RDS
(RDBMS) Networking
VPC
(仮想プライベートクラウド)
Route53
(DNSホスティング)
Direct Connect
(専⽤線接続)
他にはIAM（権限管理）やCloudWatch（監視）など。
オンプレからの移⾏ではほぼこれらのコンポーネントだけでシステムが成⽴する
移⾏先の
サーバ本体
webサーバの
負荷分散
静的ファイル
置き場等
RDBMS本体
クラウド内の
プライベート
ネットワーク
DNS権威サーバ
オンプレとの
プライベート接続

Content Index
SECTION 1
SECTION 2
SECTION 3
SECTION 4
実践編

  今回はインフラ構築を題材にしています
  アプリ開発については全く触れていません
  ごめんなさい
おことわり

システムを作るとどんな作業が待っているか
要件
定義
設計
構築
運⽤
•  ネットワーク構築
•  仮想サーバ構築
•  ミドルウェア構築
•  ドメイン取得・移管・登録
•  各種セキュリティ設定・構築
•  etc…
•  バックアップ
•  監視
•  ログ分析
•  キャパシティプランニング
•  脆弱性モニタリング＆対応
•  セキュリティ運⽤
•  インシデント対応
•  障害対応
•  各種監査対応
•  etc…
•  ネットワーク設計
•  サーバ設計
•  ミドルウェア設計
•  可⽤性設計
•  サイジング
•  セキュリティ設計
•  運⽤設計
•  etc…

AWSでシステムを作るとどんな作業が待っているか
要件
定義
設計
構築
運⽤
•  AWSアカウント取得
•  IAM設定
•  VPC構築
•  EC2構築
•  etc…
•  監視
•  ログ分析
•  障害対応
•  etc…
•  運⽤設計
•  VPC設計
•  EC2設計
•  etc…

  やることの本質はあまり変わらない
  ある程度⼿順を簡略化・⾃動化することは出来る
  オンプレミスでバラバラに構築するより簡単に⾃
動化が出来る
  もちろんAWSだけでは出来ないこともある
  適宜要件を満たすためのインテグレーションが必要
  AWS向けのサードパーティ製品も充実している
実は…

Content Index
SECTION 1
SECTION 2
SECTION 3
SECTION 4
実践編

設計

設計
要件
定義
設計
構築
運⽤
•  AWSアカウント取得
•  VPC構築
•  EC2構築
•  etc…
•  監視
•  ログ分析
•  障害対応
•  etc…
•  運⽤設計
•  VPC設計
•  EC2設計
•  etc…
設計タスク

 設計タスクには特殊なツールは存在しない
 設計の考え⽅は基本的にオンプレミスとさ
ほど変わらない
  ただし独特の考え⽅は存在する
設計
設計タスク

 可⽤性設計
  サービスの継続性に関する設計
•  障害は発⽣するものという前提で設計する
•  障害をカバーできる設計が重要
  どの規模の障害を想定するのか
•  インスタンス単体（ホスト）の障害
–  Auto Recovery や Auto Healingでカバー
•  データセンター単体の障害
–  Availabillity Zone（収容DC）の分散でカバー
•  リージョン（地⽅）全体の障害
–  別リージョンへのレプリケーションでカバー
設計
設計タスク

 VPC設計
  いわゆるネットワーク設計
  接続性（インターネット、オンプレミス、他
VPC等）
  IPアドレス設計
•  VPC全体のアドレス空間をどう割り当てるか？
–  VPC⼀つで最⼤で /16 のアドレス空間
–  オンプレミスと閉域接続するならば、相互到達性の確保の
ため、アドレス帯の重複はNG
–  拠点側のルーティングも考慮する
•  サブネットの分割
設計
設計タスク

 セキュリティ設計
  インフラセキュリティ設計
•  AWSネイティブの機能で出来ること
–  L4ステートフルファイアウォール（Security Group）
–  パケットフィルタ（NetworkACL）
•  出来ないこと
–  IPS/IDSやマルウェア対策等の⾼次元なセキュリティ対策
»  サードパーティ製品を組み合わせる
  アカウントセキュリティ設計
•  ユーザアカウント管理（IAM）
–  権限の設計（IAMポリシー）
–  認証の設計（IDフェデレーション、MFAなど）
設計
設計タスク

構築・運⽤

構築フェーズ
脆弱な環境を撲滅するためにしたいこと(1)
AWSアカウント取得後の設定
• AWS推奨のアカウントセキュリティ設定
IAMアカウントの発⾏と積極利⽤
• rootアカウントは極⼒⽤いない
• IAMユーザを発⾏する、適切な最⼩権限を割り当てる
• 認証設定（MFAの利⽤）
操作ログの全記録
• CloudTrailを有効化して、全ユーザの操作ログを記録

構築フェーズ
脆弱な環境を撲滅するためにしたいこと(2)
環境構築作業の⾃動化・省⼒化
• CloudFormationを使って環境をコードで可視化
• 構築のレビューをコードレビューの感覚で
• 極⼒マネジメントコンソールを操作せず、⾃動化により⼿
作業による構築ミスを撲滅
IAMロールの積極活⽤
• EC2インスタンス上のアプリケーションから各AWSリソー
スへのアクセスにクレデンシャルを使わない
• 多くのサービスでIAMロールを前提にしているため、特に
予定が無くても有効にしておく（IAMロールは後から有効
化出来ない）

AWSアカウントを取得したら
最初にすべきこと＆ IAM

  rootアカウントはAWS環境に対するフルアクセス権限を持つので、厳重に管理する必
要がある
  この作業はアカウント取得直後に実施することを推奨
AWSアカウントを取得したら最初にすること
rootアカウントのセキュリティ設定修正
rootのアクセス
キー削除
rootアカウントのアクセスキーを削除し、IAMユーザのアクセス
キーもしくはセキュリティトークンを使⽤する。
rootアカウント
でMFAを有効化
已むを得ずrootアカウントを使⽤するときのため、rootアカウ
ントのMFA（⼆要素認証）を設定する
各利⽤者⽤の
IAMユーザ作成
複数の利⽤者でrootアカウントを使い回すことが無いよう、利
⽤者毎のIAMユーザを作成する
グループ単位の
アクセス許可
利⽤者毎に個別にIAMポリシーを管理すると破綻するので、ポリ
シー毎にグループを作成し、IAMユーザをグループに所属させる
IAMパスワード
ポリシーの設定
脆弱なパスワードを使うことが無いよう、パスワードポリシー
を決める

  rootのアクセスキーがあれば、全APIにフルアクセスが可
能であるため、アクセスキーは必ず削除する
rootアカウントのアクセスキー削除
必ず削除！

  マネジメントコンソールへのrootアクセスそのものは禁⽌できない
が、MFAを有効にすることで認証の強度を⾼めることが重要
  IAMユーザでも積極的に利⽤したい
rootアカウントのMFA有効化
Google Authnticator・Authy・IIJ SmartKeyなどが仮想MFAデバイスとして利
⽤可能。久保のオススメはiPhone6以降(Touch ID対応端末)+IIJ SmartKey。
SmartKeyの起動認証としてTouch IDが利⽤できて安⼼。

  利⽤者ごとの権限管理と⾏動証跡管理のため、必ず利⽤者毎にIAM
ユーザを発⾏する
  間違ってもアカウント(root含む)の共⽤をやってはいけない
各利⽤者のIAMユーザ作成

  IAMではユーザごとに個別のポリシーを適⽤可能だが、
利⽤者が増えてくると管理が煩雑になる
  権限毎にIAMグループを作成し、ユーザを作成したら適
した権限のグループに所属させる運⽤が効率的
グループ単位のアクセス許可

  デフォルトの状態ではIAMパスワードにポリシーは定義
されていない
  脆弱なパスワードにされていると全ての施策が無駄にな
るので、強固なパスワードポリシーを設定する
IAMパスワードポリシーの設定

こうなっていればOK

操作ログの全記録

  CloudTrailのススメ
  AWSでは、多くの操作がその裏側でAPIをコールしている
•  マネジメントコンソールの操作
•  コマンドラインの実⾏
•  等
  CloudTrailはAPI実⾏ログを記録することで、ユーザがど
んな操作を⾏ったかを追跡するサービス
AWSの利⽤状況を監視する
API利⽤ログの記録と監視
マネジメント
コンソール操作
AWSCLIでの
操作

  CloudWatch Logsとの連携
  CloudTrailのログは“S3への保管”と“CloudWatch Logsへのログ
ストリーム提供”が可能
  CloudWatch Logsに提供したログストリームは、CloudWatch
側のメトリックスフィルタの機能を使って、「特定の条件にマッ
チしたログを検知してメールで通知する」事が可能
•  マネジメントコンソールへのログイン、利⽤を想定していない操作を検知する、
等
AWSの利⽤状況を監視する
CloudTrailの応⽤例

構築作業の簡略化・省⼒化

  ⼤量のサーバのOSセットアップをするという単純作業で
⼀週間も掛かってしまった
  同じ作業をダラダラ繰り返していたら、設定を間違えて
しまった
  前に納品した案件とほとんど同じ構成をまた⼿作業で構
築している
こんなことって経験ありませんか

  CloudFormationとは
  AWSに特化（専⽤）したオーケストレーションツール
  AWSの各種リソースの構築後の状態（“スタック”と呼ぶ）を予めコード
で定義しておくことで、システム⼀式の構築を⾃動化できる
  各種リソースはJSON形式で記述する（CloudFormationテンプレー
ト）
  ※当社では構築作業で標準採⽤。今回のデモ環境も同様
CloudFormationでボタン⼀発の環境構築

  JSONファイルの準備
  事前に構築後の各リソースの状態を⽰すJSONファイルの準備が必要
  各リソースの指定には以下のような動的な値を渡すための様々な組み込
み関数や参照⽅式が利⽤可能
  これらを使うことで、特定の環境だけではなく汎⽤的に繰り返し利⽤で
きるテンプレートを作成可能
CloudFormationを使ってみる
擬似パラメータスタックの作成時に動的に⼊⼒する値をパラメータとして私⽤
組み込み関数 Fn::GetAtt ：テンプレートのリソースから属性値を返す
Fn::FindInMap ：Mappingsで指定したセクションでパラメー
タのマッピング挿⼊を⾏う
Fn::GetAZs ：指定したリージョンのAZ⼀覧を配列で返す
など

CloudFormationのポイント
• コードを書く⼿間は必要だが、⼿作業に⽐べて構築⼿順を簡略化・省⼒化することは可能
構築作業の簡略化
• マネージメントコンソールを操作して⼀つ⼀つ⼿作業で構築する場合に⽐べて、⼿作業に
よる作業ミスは低減することが可能
⼿作業によるミスを軽減
• 様々な組み込み関数や参照を使⽤することで、汎⽤的なテンプレートを作成できるため、
似たような環境の構築を簡単に⾏うことが出来る
• また、構築した環境の削除も「スタックの削除」によってボタン⼀発で可能
汎⽤的なテンプレートによる同様の環境構築の省⼒化
• 各リソース間には依存関係があるものが存在するため、これらリソースの定義順序に注意
が必要であり、テンプレートの作成にはAWSサービスに関する知識がある程度必要となる。
• 例）VPCやサブネットを定義する前にEC2インスタンスを定義するとスタックの構築に失
敗する、など
リソースの依存関係に注意

  ⼤量の構築はCloudFormationでボタン⼀発で終わらせま
しょう
  ⼿作業による設定ミスの削減にもつながります
  ⼀度やった仕事を繰り返すのはやめて省⼒化しましょう
まとめ

オペレーションの簡略化

  Heartblead対応でOpenSSLのバージョンアップ作業。
頑張って⼀台ずつ、Webサーバ20台全てを対応したと
思ったら1台忘れてた
  アプリ開発チームにPythonのライブラリを⼊れてと急ぎ
お願いされたけど、⼀台ずつ設定するの⾯倒くさい。。。
  開発・運⽤・構築チームそれぞれがOSにログイン出来る
権限を持っていて、権限管理が⼤変
こんな経験ありませんか

  EC2 Run Commandとは
  指定した複数台のEC2インスタンスに対してコマンドを⼀括実⾏
する便利な機能
  コマンドの実⾏はOS側の認証ではなく、AWSのIAMポリシーと
ロールで制御する。このため、特定のオペレーションのために
OSにログイン出来るユーザを限定することが出来る
  CloudTrailと統合されており、コマンド実⾏結果はCloudTrail側
で保管されるためプロセスアカウンティングの⼿段としても有効
EC2 RunCommandでコマンド⼀括実⾏

  対象となるインスタンスの準備
  SSMエージェントを事前にインストール
•  UserDataでインスタンス起動時に有効化しておく
と良い
–  “AmazonEC2RoleforSSM”というIAMポリシーを対象いスタンスのIAM
ロールにアタッチしておく
EC2 RunCommandを使ってみる

  やりたいことを選ぶ（Linuxだったらほぼ選択肢無し）
  対象のインスタンスを選ぶ
  任意のコマンドを⼊⼒して実⾏する
EC2 RunCommandを使ってみる

  実⾏結果はマネジメントコンソールからいつでも確認可能
実⾏完了

EC2 RunCommandのポイント
• ⼤量のWebサーバに⼀気にパッチを当てる、といった⽤途に適している
⼀括実⾏による作業負荷の軽減
• ⼿作業に⽐べ、作業漏れによる脆弱性の放置リスクを低減することが可能
脆弱性対応に
• また、⼀台⼀台⼿作業することに依るオペレーションミスも低減可能
オペミスのリスク低減
• IAMロールはインスタンス作成時にしかアタッチ出来ない（アタッチされている
ロールに後からポリシーのアタッチは可能）ことが唯⼀の⽋点
対象のインスタンスにはIAMロールが必要

セキュリティ診断をしよう

 Amazon Inspector
  対象のインスタンスにセキュリティ診断を実
⾏、レポートしてくれる機能
  以下の観点(Rules packages)で評価
•  CIS Operatiing System Security Conﬁguration Benchmarks
•  Common Vulnerabilities and Exposures
•  Security Best Practices
•  Runtime Behavior Analysis
セキュリティ診断の⾃動化

  Amazon Inspectorの利⽤
  対象のインスタンスにセキュリティ診断を実⾏、レポートしてく
れる機能
  対象のインスタンスにエージェントをインストール
  Inspectorを実⾏するためのIAMロールを作成（既に作成してい
る場合は選択する）
  診断対象のインスタンスにタグ付けする
Amazon Inspectorを使ってみる

  Amazon Inspectorの利⽤
  評価ターゲットの作成
•  ターゲットとなるインスタンスに共通のタグを作成する
•  例）”Sys”->”JNSA-20160825”
  評価テンプレートの作成
•  ターゲットとルールの選択
•  所要時間の選択(15分〜24時間)

  分析完了
実⾏結果126
件の指摘事項

  レポートを⾒る
CVEに登録されている重要
度Highの脆弱性だらけ

Amazon Inspectorのポイント
• 対象のリソースを同じタグでグルーピングしておくことで、⼤規模なシステムに対しても
簡単に診断が可能
対象のシステムに対する⼀括診断
• インストールされているミドルウェアの脆弱性だけでなく、OSのセキュリティ設定や
AWS独⾃のセキュリティ設計に関する診断（例：アクセスキーをAWS CLIのローカルコン
フィグに記録している等）が可能
様々な切り⼝での診断
• APIやCLIに対応しているので定期的な診断が可能。また、ターゲットは設定されたタグに
よって⾃動的に収集されるため、新たにインスタンスが増加してもタグを設定しておけば
⾃動的に診断対象となるため、環境の変化に⾃動的に追従する
繰り返しの実⾏が可能
• IAMロールはインスタンス作成時にしかアタッチ出来ない（アタッチされているロールに
後からポリシーのアタッチは可能）ことが唯⼀の⽋点
対象のインスタンスにはIAMロールが必要

構成管理をしよう

  誰がリソースを触っているかも分からないし、ど
のリソースが何時どのように変更されたか全くわ
からない
  t2.microで⽴てた検証⽤インスタンスがいつの
まにかm4.largeになってる。誰だ。。。
  会社からしか繋がらないはずのサーバが、いつの
間にか特定の外部から繋がるようにSecurity
Groupがこっそり変更されている
こんな経験ありませんか

  AWS Conﬁgを使った構成管理
  AWSの様々なサービス／リソースの構成情報を管理する
  前述のCloudTrailが“APIの使⽤履歴”を管理するのに対して、
AWS Conﬁgは“リソースの変更履歴”を管理する
  変更履歴はS3のバケットに保管される
  SNSとの連携した変更通知も可能
AWSリソースの構成管理

 設定は簡単
  記録するリソースの種類の選択
  記録を保存するS3バケットの選択（作成）
  変更を通知するSNSトピックの選択（作成）
  リソースをRO権限で監視するIAMロール
AWS Conﬁgを使ってみる

 確認するリソース毎に履歴を表⽰
変更履歴を確認する
時計アイコンをクリックす
ると変更履歴が表⽰される

時系列で変更履歴を確認
2016/02/26 4:35:36 PM
に4件の変更があった

変更管理をしよう
変更内容を確認する
パブリックIPアドレスが新
たに割り当てられたことが
分かる（ほかは割愛）
 どんな変更が加えられたか⼀⽬瞭然

  AWS Conﬁg Rules
  予め決めたルールに準拠していないリソースを検出する
  ルールはカスタムで作成可能。2016.08時点で以下のマネージ
ドルールがある
•  EC2インスタンスのテナンシーチェック
•  rootアカウントのMFA設定チェック
•  EBSボリューム暗号化チェック
•  CloudTrail有効化チェック
•  EIPアタッチのチェック
•  接続元無制限のSSHチェック
•  インスタンスのVPC所属チェック
•  指定タグチェック
•  ⼀般的なポート開放チェック
  カスタムルールはLambdaファンクションで実装、違反を検知し
て構成を変更（強制）といったアクションも実装出来る
リソースのルール管理をする

ルール違反のリソースを⾒つけ出す
ボリューム暗号化を使⽤していない
EBSボリュームが13個存在する
違反リソースの
確認
履歴の確認

  AWS ConﬁgでAWS各種リソースの変更履歴を管
理できる
  変更履歴は事実上容量無制限のS3上に保存され
るため、半永久的に記録し続けることが可能
  Conﬁg Rulesを使えば、更にポリシーに合致し
ないリソースを検出し、あるべき状態を維持する
ことが出来る
変更管理をしよう
まとめ

もう少し突っ込んだ話

データ保護

  仮想サーバのストレージ暗号化
  EC2(EBS)ではボリュームの暗号化を選択可能
  AES-256アルゴリズムで暗号化
  ボリューム内のデータ／ボリューム⇔インスタンス間を移動する
データ／ボリュームから作成したスナップショットが暗号化され
る
  ただし、EBS暗号化をサポートするインスタンスタイプは限られ
ているため注意が必要
  RDSのストレージ暗号化
  DBのストレージ暗号化を選択可能（全DBMS）
  AES-256アルゴリズムで暗号化
  但し、Auroraの暗号化スナップショット暗号化は未サポート
  キーはAWS KMS（Key Management Service）で管理可能
データの保護
AWSで利⽤できるデータ保護

  Amazon S3でのデータ保護
  サーバ側キーによるデータ保護（SSE）
•  AWS側で管理する鍵
•  ユーザ側で作成したキー（SSE-C）
•  が選択可能
  クライアント側キーによるデータ保護（CSE）
  オブジェクト単位で設定が可能
データの保護
AWSで利⽤できるデータ保護

AWS単体では実現が難しいこと

  以下の機能については、現状AWSでは提供されていない
  利⽤者側で独⾃に対策が必要
  ゲートウェイセキュリティ
  IPS／IDS
  次世代ファイアウォール、DBファイアウォール
  DDoS
  エンドポイントセキュリティ
  マルウェア対策
  改ざん検知
  等
AWSが提供していない機能

  AWSをサポートする製品、AWSの仮想マシンイメージ（AMI）とし
て様々な製品が提供されている
  必要に応じてこれら製品の活⽤を推奨（下はごく⼀部）
豊富な3rd-party製品の利⽤

まとめ

  リソースをセキュアに構築・維持するためのツー
ルはかなり揃ってきた
  が、まだまだ使われていない
  ツールを使いこなせば、かなり⽔準の⾼いインフ
ラ環境がお⼿軽に⼿に⼊る
  ⼀⽅で、IaaSを利⽤する上でOS以上のレイヤー
についてはAWSでは管理できない
  商⽤製品とAWSネイティブの機能のインテグ
レーションが⾮常に重要
  とりあえず予定がなくてもIAMロール付けてイン
スタンスを⽴てよう
まとめ
AWS環境をセキュアに構築・運⽤するコツ

AWSという便利な環境を使って
システム構築・運⽤を楽にしていきましょう

JNSA西日本支部技術研究WG AWSを使ったセキュアなシステム構築

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (6)

Similaire à JNSA西日本支部技術研究WG AWSを使ったセキュアなシステム構築

Similaire à JNSA西日本支部技術研究WG AWSを使ったセキュアなシステム構築 (20)