JAWS-UG 情シス支部 #3

セキュリティポリシーがない組織でもAWSで最低限やるべきことを議論しよう

（EC2を中心に使うケース）

2016年6月16日

Nobuhiro Nakayama

JAWS-UG 情シス支部 #3

{

"name":"Nobuhiro Nakayama",

"company":"UCHIDAYOKO CO., LTD.",

"favorite aws services":[

"Directory Service",

"IAM",

"AWS CLI"

],

"certifications":[

"AWS Certified Solutions Architect-Professional",

"AWS Certified SysOps Administrator-Associate",

"Microsoft Certified Solutions Expert Server Infrastructure",

"Microsoft Certified Solutions Expert SharePoint",

"IPA Network Specialist",

"IPA Information Security Specialist"

]

}

こんな風景ありませんか？

セキュリティ対策、ちゃんとやってね。

はい！

・・・

＿人人人人人人人人人＿＞ちゃんとってなんだ！＜￣Y^Y^Y^ Y^Y^Y^Y^Y^￣

セキュリティポリシーを策定している企業は少ない

• セキュリティポリシーを定義している企業の割合

• 小企業 9.6%

• 中企業 25.3%

• 大企業 58.8%

「2015年度中小企業における情報セキュリティ対策に関する実態調査」報告書についてhttps://www.ipa.go.jp/security/fy27/reports/sme/index.html

調査報告書 P17 情報セキュリティ対策への取り組み状況https://www.ipa.go.jp/files/000051252.pdf

様々な業界標準

• 金融

• FISC https://aws.amazon.com/jp/aws-jp-fisclist/

• 医療・製薬

• GxP コンプライアンス https://aws.amazon.com/jp/compliance/gxp-part-11-annex-11/

• クレジットカード

• PCI DSS https://aws.amazon.com/jp/compliance/pci-dss-level-1-faqs/

• 会計

• SOC https://aws.amazon.com/jp/compliance/soc-faqs/

• ISO

• 9001 https://aws.amazon.com/jp/compliance/iso-9001-faqs/




https://aws.amazon.com/jp/aws-jp-fisclist/

https://aws.amazon.com/jp/compliance/gxp-part-11-annex-11/

https://aws.amazon.com/jp/compliance/pci-dss-level-1-faqs/

https://aws.amazon.com/jp/compliance/soc-faqs/

https://aws.amazon.com/jp/compliance/iso-9001-faqs/




∧_∧ ⊂（#・ω・）できるかー！！

/ ﾉ∪ し―-J |l| |

人ﾍﾟｼｯ!! ＿＿＼＼

￣￣

クラウドならセキュリティ万全なんだろ？

はい！

・・・

＿人人人人人人人人人＿＞部分的にはな！＜￣Y^Y^Y^ Y^Y^Y^Y^Y^￣

責任共有モデル

（補足）そもそも、セキュリティって？

• 以下の3要素で構成

• 機密性（情報を保護できること）

• 完全性（情報が正しいこと）

• 可用性（情報にアクセスできること）

どうすればいいんだー！

• ポリシーが無いなら、黙ってベストプラクティスに従うところから

• 余裕があれば、業界標準を利用するのもあり

• レベルが高すぎたり、低すぎたりする場合もある

• リスクアセスメントは大変・・・

• 実践を通してポリシーを確立していけばいいのでは？

• ホワイトペーパーがあるので読んでみよう

• AWS Security Best Practices

• https://aws.amazon.com/jp/whitepapers/aws-security-best-practices/

• （日本語もあるよ）

https://d0.awsstatic.com/International/ja_JP/Whitepapers/AWS_Security_Best_Practices.p

df

https://aws.amazon.com/jp/whitepapers/aws-security-best-practices/

https://d0.awsstatic.com/International/ja_JP/Whitepapers/AWS_Security_Best_Practices.pdf

AWS Security Best Practicesを読んでみた

2016年6月16日

Nobuhiro Nakayama

JAWS-UG 情シス支部 #3

この議題の狙い

• 「もやもや」を解消

• 「一般的にはどこまで対策するべきなのか？」

• 「他の組織ではどこまでやってるのかな？」

• 「オレオレセキュリティポリシーのままでいいのだろうか・・・」

• 気づきを得る

• 「あ、その対策やってねぇ・・・」

• 「あのリスクに対してそんなアプローチもあるのか！」

• 「そのリスク、見落としてた・・・」

質問

AWS Security Best Practicesというホワイトペーパー、ちゃんと読んだことありますか？

AWS Security Best Practices （要約から抜粋）

• このホワイトペーパーは、アマゾンウェブサービス（AWS）で実行するアプリケー

ションのセキュリティインフラストラクチャと設定を、現在設計している、または今後

設計することをお考えのお客様を対象としています。このホワイトペーパーでは、AWS

クラウド内のデータと資産を保護できるように Information Security Management

System (ISMS) を定義し、各組織用の一連のセキュリティポリシーとプロセスを作成す

るのに役立つセキュリティのベストプラクティスについて説明します。また、AWS での

資産の識別と分類と保護、アカウント、ユーザー、グループを使用した AWS リソース

へのアクセスの管理、さらにはクラウド内のデータ、オペレーティングシステム、アプ

リケーション、およびインフラストラクチャ全体を保護するために推奨される方法など、

セキュリティに関するさまざまなトピックの概要についても説明します。

https://d0.awsstatic.com/International/ja_JP/Whitepapers/AWS_Security_Best_Practices.pdf

OSの中のことまで言及している

AWS Security Best Practices

1. 責任共有モデルを正しく理解する

2. 保護対象の情報資産の整理

3. 情報セキュリティ管理システムの設計

4. AWSアカウント、IAMユーザ・グループ・ロールの管理

5. EC2インスタンスの管理

6. データの保護

7. OSとアプリケーションの保護

8. インフラストラクチャ（VPCなど）の保護

9. モニタリング、通知、監査、インシデントレスポンス

とりあえず・・・

• いきなり完璧は目指さない

• 継続するためにムリはしない

• 今できていることや、AWSのサービスで手軽にできることからはじめよう

• まずは読んでみよう！

• 知らないのはダメ（無責任にもほどがある）

• 事業や業務の特性に応じて、やる／やらないを判断しよう

本編に入る前に

• ちゃんと理解する場合は、自分で全部読みましょう！

• 結構、端折ってます

• 2013年の11月のホワイトペーパーなので、最新のサービスについては言

及が無いです。

• 更新待ってます！











覚えておくべきこと

• 全部AWSに丸投げできるわけではない

• ユーザが責任を負う部分がある

• Trusted Advisorがある程度問題を指摘してくれる（対策の実施はユーザの責任）

• コンポーネント単位の障害が発生してもシステムに影響がないようにするのはユーザの

責任

• Design for Failure

• AWSは耐障害性を高めるための選択肢を用意している

• 冗長化せずにリスクを受容するのも選択肢の一つ

• サービスの種類によって責任範囲が異なる

• Infrastructure services < Container services < Abstracted services

• マネージドなサービスを可能な限り利用して、責任範囲を少なくすることができる

サービスによって異なる責任分解点

http://www.slideshare.net/AmazonWebServices/masterclass-advanced-security-best-practices















要チェックの情報資産

• 機密情報の有無は絶対確認！！

• クレジットカード

• マイナンバー

• 人事情報、その他の個人情報

• ネットワーク（インターネット回線、専用線・閉域網）

• クラウド化でこれまでより重要性が上がっている

• Credential（パスワード、APIキー、ハードウェアトークンなど）

• 見過ごされやすいけど、めっちゃ重要

• まずは保護対象であると明示的に認識するところから

• その他

• ホワイトペーパーを確認してください（丸投げ）











情報セキュリティ管理システムの設計

• ISMSの構築に関するフレームワークについて紹介

• 詳細は割愛











AWSアカウント、IAMユーザ・グループ・ロールの管理（１）

• IAMユーザは共有せずに一人ずつ作成する（共有、ダメゼッタイ）

• IAMグループを使って権限付与をシンプルに

• 必要最低限の権限を付与する

• 強い権限を持つユーザでは多要素認証を利用

• IAMの権限、リソースの作成・削除・変更、ログ関連など

• APIキーのご利用は計画的に

• 定期的なローテーションが推奨されている

AWSアカウント、IAMユーザ・グループ・ロールの管理（２）

• AWSアカウント（root）は常用しない

• MFAで保護

• AWSアカウントは要件に応じて複数作成することも検討

• アカウントを複数作成する場合、クロスアカウントアクセスの設定を検討

• AWSアカウントを複数管理する場合の戦略や一時的な認証情報を利用し

た委任についても言及











OSにアクセススための認証情報

• 秘密鍵の管理

• SSH接続時の認証情報（Linux）

• WindowsのAdministratorsのパスワードの発行

• 可用性の高いストレージへの保管／アクセスログ／厳密なアクセス制御

• （可能なら）Acrive DirectoryやLDAPとの認証連携

• デフォルトのユーザ（ec2-user/Administrator）は可能な限り使用しない

• （Windowsの場合）ec2configでAdministratorのパスワードリセットも可能











データの保護（１）

• リソースへのアクセス制御

• IAMでの制御とサービス側での制御（S3のBucket Policyなど）の2種類がある

• S3での意図しないデータの公開などにも注意

• バックアップ（データ／システム）

• AWSに起因するデータの消失確率は低い（しかし、0ではない）

• オペミスによるデータの消失リスク

• スナップショット、レプリケーション、バージョニングなど

データの保護（２）

• 通信の暗号化

• SSL/TLS、Ipsec、閉域網など

• 大量のデータを移行する場合、Snowballなども検討

• （必要に応じて）データの暗号化

• 暗号化のための鍵管理はサービスとして提供されている（KMS、CloudHSM）

• S3のサーバサイド暗号化などは、認証されたユーザ／OSからは透過的にアクセスで

きるので、何のリスクに対応できるかは正しく認識しておく必要がある











OSとアプリケーションの保護（１）

• AWS特有の対策

• 出所が不明なAMIを使わない

• 適正利用規約に違反しない

• https://aws.amazon.com/jp/aup/

• AWSに監視されています

• セキュリティに関する連絡用のメールアドレスを設定することが可能

https://aws.amazon.com/jp/aup/

OSとアプリケーションの保護（２）

• 一般的な対策

• パッチの適用

• マルウェア対策

• デフォルト設定を使わない（セキュアでなければ）

• 不要なユーザを作らない

• １つのサーバに複数の役割を同居させない

• 不要なサービスやリソースを排除／アンセキュアなサービスを使わない

【参考】Center for Internet Securityが提供するAMI

https://aws.amazon.com/marketplace/seller-profile/ref=sp_mpg_product_vendor?ie=UTF8&id=6b3b0dc2-c6f4-487b-8f29-9edba5f39eed











インフラストラクチャの保護（１）

• VPCを使う

• IP-Sec、Direct Connectなどによるサイト間接続

• VPC Flow Logでフロー情報（データ部分は含まない）を収集

• セグメンテーション

• DMZ/Internalなど、役割等に応じてレイヤーを定義

• ネットワークセキュリティの強化

• 基本的にSecurity Groupで十分（ステートフル）

• 必要に応じてNACLを併用（ステートレスなので設計に注意）

インフラストラクチャの保護（２）

• AWSが提供するDNS、NTPを利用する

• 自前で運用するよりリスクは低い

• 脅威保護

• WAF、IPS/IDSなど

インフラストラクチャの保護（３）

• （公開サーバがある場合）セキュリティテスト

• 申請に基づき侵入テストを実施することが可能

• （公開サーバがある場合） DDoSなど外部からの攻撃への対策

• DDoSの発生自体を防ぐことは困難

• モニタリングと検知後の緩和対策を策定











モニタリング、通知、監査、インシデントレスポンス（１）

• 何を監視すべきか明確にする

• 特権ユーザによる操作全般

• 認証の成功と失敗

• 監査証跡へのアクセス

• システムレベルのアクセス

• ログの取得方法

• AWSのリソースに対する操作は、CloudTrailで取得可能

• OSやアプリケーションに関する操作は別途検討（CloudWatch Logsもある）

モニタリング、通知、監査、インシデントレスポンス（２）

• 通知条件

• どんなイベントを把握したいか

• インシデントレスポンス

• 問題が発覚したときにどうするか

• システムの一時的な停止などの対策および対策の実施を判断するための基準

• このあたりは外部の迷惑をかける可能性があるので、きちんと考えておくべき

• ログの保管

• 改竄できないこと

リソースはいろいろあるよ

• セキュリティセンター

• https://aws.amazon.com/jp/security/?nc2=h_l2_tr

• コンプライアンスセンター

• https://aws.amazon.com/jp/compliance/?nc2=h_l2_tr

• ホワイトペーパー等

• https://aws.amazon.com/jp/security/security-resources/

https://aws.amazon.com/jp/security/?nc2=h_l2_tr

https://aws.amazon.com/jp/compliance/?nc2=h_l2_tr

https://aws.amazon.com/jp/security/security-resources/

おすすめ資料

• Advanced Security Best Practices Masterclass

• http://www.slideshare.net/AmazonWebServices/masterclass-advanced-security-

best-practices


Technology

JAWS-UG 情シス支部 #3