Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Masahiro NAKAYAMA, profile picture
Uploaded byMasahiro NAKAYAMA
PDF, PPTX4,675 views

クラウドセキュリティ基礎 #seccamp

2016-08-11 セキュリティ・キャンプ全国大会2016 クラウドセキュリティ基礎 最新版はこちら ⇒ http://www.slideshare.net/nekoruri/20161126-cloud-security-aomori

Technology◦
Related topics:
Cloud Computing Insights• Information Security•
Download as PDF, PPTX
クラウドセキュリティ 基礎 株式会社WHERE IoT基盤センター サービスプロデューサー 兼 情報システム室 インフラエンジニア 仲山 昌宏 ( @nekoruri )
講師プロフィール • 仲山昌宏 • いわゆるセキュリティエンジニア……ではありません • 秋葉原生まれ大手町育ちの 歌って踊れる江戸っ子インフラエンジニア • 株式会社WHERE IoT基盤センター サービスプロデューサー 兼 情報システム室 インフラエンジニア 2
経歴 • 2003-09～2005-03 大学院ネットワーク管理 • 2004-03～2010-06 WIDE Project irc.fujisawa.wide.ad.jp運用 • 2004-09～2005-10 国際大学GLOCOM (研究アシスタント) • 2005-08～2008-09 AIP • 2008-10～2009-12 KBB, I&D • 2010-01～2013-06 Xtone • 2013-07～2016-01 CyberAgent (パシャオク⇒Ameba⇒DC運用) • 2016-02～現職 WHERE (測位技術スタートアップ) ⬅今ここ 学 生 社 会 人 1999-04 ↓ 2006-03 2006-03 ↓
主なスキルセット • システム設計 • クラウドとIoTデバイス組み合わせて 良い感じのシステム • ウェブアプリの内部アーキテクチャ • アプリケーション開発 • メインはサーバサイド Perl、Ruby、Python、JS、PHP • 過去にはWindowsとかも • 最近IoTデバイスの内蔵マイコンにも 手を出し始めた • 情報システム • 社内ITシステムの設計、運用 • 情報セキュリティマネジメント • サーバ/ネットワーク運用 • サーバHW（特にストレージ）周り • IPネットワーク • 「必要があればなんでもやる」 4
この講義の目的 • クラウド時代のWebシステムについて • サーバ設計、構築、運用技術の基礎 • サービスの無停止とスケーラビリティを実現する設計 • 継続的インテグレーション、高速なリリースサイクル • クラウドのセキュリティ • ID管理と監査 • セキュリティマネジメント • 演習 5
サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ 6
経歴 • 2003-09～2005-03 大学院ネットワーク管理 • 2004-03～2010-06 WIDE Project irc.fujisawa.wide.ad.jp運用 • 2004-09～2005-10 国際大学GLOCOM (研究アシスタント) • 2005-08～2008-09 AIP • 2008-10～2009-12 KBB, I&D • 2010-01～2013-06 Xtone • 2013-07～2016-01 CyberAgent (パシャオク⇒Ameba⇒DC運用) • 2016-02～現職 WHERE ⬅今ここ 学 生 社 会 人 1999-04 ↓ 2006-03 2006-03 ↓ 前職の話が分かりやすいと思うので、 CA社を例に挙げて説明します。
株式会社サイバーエージェント • 「アメーバで検索検索♪」の会社 • 半分が広告事業 • 広告の配信システム • 広告の斡旋 • 残りの半分がゲーム事業 • 「グラブル」 • 「デレステ」「モバマス」 • 残りがメディア事業 • アメブロ、AbemaTV 8 https://www.cyberagent.co.jp/ir/about/factsheet/
サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2016年3Qのゲーム事業売上高：306億円（四半期決算） （2016/04/01～2016/06/30：91日間） • 1時間あたり1,401万円（1分あたり23万円） 9 毎分23万円、稼ぎ時ならその何倍か 安いような高いような……
サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2016年3Qのゲーム事業売上高：306億円（四半期決算） （2016/04/01～2016/06/30：91日間） • 1時間あたり1,401万円（1分あたり23万円） • ピークタイム（稼ぎ時） • 期間限定イベントのラストスパート • 月初（キャリア決済の限度額がクリア） • 年始めのおみくじ代わり 10 「障害時の損失」は、 「普段稼いでいる金額」でもあります。
サービスの運用とは • 目的： • ITを使って「お金を稼ぐ」 • 手段： • お客さんにサービスを提供し、その対価を受け取る （直接部門） • 従業員にサービスを提供し、生産性を向上させる （間接部門） 11 運用とは、 サービスの価値を届け続けることです。
サービスの価値 • 使いたいときに使える（落ちない）こと • いわゆる「サービスの品質」 12 サービスの価値を決めるのは、一つは、 それが期待通りに動いていることですが……
サービスの価値 • 使いたいときに使える（落ちない）こと • いわゆる「サービスの品質」 • そもそも： • サービスの内容がお客さんの期待を満たすこと 13 サービスの価値を決めるもう一つは、 それが期待通りの内容であることです。
サービスの価値を高める努力 （サイバーエージェントの場合） 1. 膨大な新サービスを続々とリリース • 2015年だけで10サービス以上の提供を開始 2. 頻繁な人材流動で開発体制を最適化 • 2011年 スマホシフト、2014年 アメーバ構造改革 3. 明確な撤退ルールで失敗と正しく向き合う • リリースから2年を目処に成果が出なければ撤退 14 価値を高め「続ける」こと が最大の課題です。
インフラ的なつらさ • 流行れば大量のサーバがすぐに必要になる • チューニングには時間が掛かり限界もある • とにかくサーバ追加で時間を「稼ぐ」（通称：金の弾丸） • 廃れればどんどん縮小させる • 縮小しきれない過剰投資は「損失」でしかない • 新しいプロジェクトには新しい技術を積極導入 • プロジェクトごとに使う技術もバラバラ • サーバの共有はむずかしい 15 多種多様なサーバを、 必要な時に必要なだけ使いたい！
それクラウドでできるよ 16
クラウドコンピューティング 17 https://www.ipa.go.jp/files/000025366.pdf
クラウドコンピューティング 18 https://www.ipa.go.jp/files/000025366.pdf イメージしづらいかもしれませんが、 要点は黄色の部分です。
クラウドコンピューティング • 要点 • 共用されたリソースプールから • いつでもどこからでもネットワーク経由で • 必要な分だけをすぐに利用できる 19
クラウド #とは NIST（米国国立標準技術研究所）による基本特徴の整理 1. オンデマンド・ セルフサービス APIでなんでもできる 2. 幅広いネットワークアクセス ネットワーク経由でできる 3. リソースの共用 共用する潤沢なリソースプールがある 4. スピーディな拡張性 すぐに利用可能 5. サービスが 計測可能であること 自らの利用量が適切に計測（されて課金される） 20 NISTの定義はあくまで「一つの定義」ですが、 それなりに広まっているものです。
クラウドの分類 運用方法による分類 • パブリッククラウド • 大規模な事業者が運用して数多くの利用者が共有 • AWSとかAzureとかいろいろ • プライベートクラウド • 社内で単独で運用 • YahooとかCyberAgentとか 21 パブリックも、プライベートも、あるんだよ。
パブリッククラウド • 大規模な事業者 • 豊富なリソースにもとづく最適化 • 膨大な開発能力にもとづく多種多様な機能 • 責任共有モデル • ざっくりOSから下は事業者がセキュリティを担保 • 各種セキュリティガイドラインへの準拠 • むしろベストプラクティスが実装された環境 • OSとその上は利用者がセキュリティを自力で担保 22 「責任共有モデル」はAmazon用語ですが、 考え方はだいたい皆同じです。
プライベートクラウド • 既存の自前でデータセンタ借りてサーバ置くモデル • OpenStackなどのクラウドコントローラでクラウド化 • 基本機能はAmazon等と似たようなことができる • 多種多様な機能は少ない • プライベートでの差別化 • 既にノウハウや購買力を持つ場合 • システム間が密結合（消極的理由） • これらを維持しつつ、クラウドや仮想化のメリットを享受 23
クラウドのサービス分類 サービス形態による分類 • SaaS • 具体的なアプリケーションとして提供される。 • DropboxとかGmailとか • PaaS • アプリケーションが動く環境が用意される。 • Herokuとか • IaaS • サーバ一式が用意される。いわゆるレンタルサーバに近い。 • ネットワーク機能（FW、LB等）も提供されたりする。 24 IaaSとPaaSの定義は既に「古い」ものですが、 この講義ではいわゆるIaaSを主に対象とします
クラウド(IaaS)でサーバを確保 • 自由なサーバの追加・削除が可能になる • すぐにサーバが増やせる！ ↔ これまでは最大想定分だけのサーバを事前に用意 ↔ 想定を超えるとすぐに対応ができない • 要らないサーバはいつでも捨てられる！ ↔ 資産の耐用年数（5年程度）を使い切れない ↔ 挑戦的なサービスをリリースできない 25 IaaSとPaaSの定義は既に「古 い」ものですが、 この講義ではいわゆるIaaSを主 に対象とします
具体的にイメージしてみよう • サーバはすぐに確保・削除できる ↓ • 作ったサーバに環境構築してすぐ本番投入したい • 本番投入中のサーバでもすぐに消したい 26
「ペット」から「家畜」へ • これまで：サーバ＝ペット • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る • これから：サーバ＝家畜 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す 27 10000匹のペットなんて 面倒見切れません
Discussion #1 クラウド環境のアーキテクチャ • Webシステムのアーキテクチャを考えてみよう • クラウド環境では何が問題になるか • どうすれば解決できるか • ポイント • 作ったサーバに環境構築してすぐ本番投入したい • 本番投入中のサーバでもすぐに消したい 28
ポイント1 作ったサーバに環境構築してすぐ本番投入したい • サーバの構築や運用の手間はかわらない • ミドルウェア入れて設定ファイルを変更 • アプリの動作に必要なライブラリも入れる • 最新のアプリケーションをデプロイ（設置） • アプリケーション設定（DB認証情報等）も設置 • アプリケーションのプロセスを起動 29 これらを全部自動化しないとねっ♪
ポイント2 本番投入中のサーバでもすぐに消したい • サーバ内に記録されたデータはどうする？ • データベース • セッション情報 • アクセスログ、エラーログ、デバッグログ • システムログ（syslog, イベントログ） • 一時的に手で入れたテスト用設定 30 思った以上にいろいろなモノを サーバの中に保存しているものです。
クラウド時代の考え方 • サーバの設計方法も合わせていこう！ • 構築や運用が楽になる方法を作る • システム全体のデータの記録方法を見直す 31 クラウドのメリットは、 考え方を整理することで最大化します！
「メリハリ」を付けよう • Statelessサーバ • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 32 責務をはっきりと分割して、 メリハリ付けて管理しましょう。
Statelessサーバの指針 • Twelve-Factor App • http://12factor.net/ja/ • （いくつか宗教的な項目もあるものの） 今までに提起された最適解の「まとめ」 33 本日覚えて帰って欲しいキーワード
Twelve-Factor App I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス 34 VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス 全て重要なのですが、時間が足りないので、 個人的に特徴的と思うポイントのみ……
Twelve-Factor App I. コードベース バージョン管理されている1つのコードベースと 複数のデプロイ • 1つのコードベース • アプリケーション全体が一つのレポジトリ • それ以外は、依存ライブラリか参照先の外部システム • 複数のデプロイ • 本番環境、ステージング環境、開発環境 • 全ての変更をきちんと記録・追跡 35
Twelve-Factor App III. 設定 設定を環境変数に格納する • デプロイごとに異なる設定 • DB接続先とかドメイン名とか • アプリ本体に設定を保存しない • 起動時に動的に設定できるようにする • あたらしい種類のデプロイをすぐ作れるようにする • ソースコードを完全に同一にできる 36
Twelve-Factor App XI. ログ ログをイベントストリームとして扱う • 時系列で継続して吐き出され続ける「ストリーム」 • アプリは吐き出すだけで、自分でファイルとかに保存しない • 開発環境ならコンソールで眺めてみんな大好き目grep • 本番環境ならログ用ストレージに転送 37
Twelve-Factor App I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス 38 VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス
じゃあ、Statefulサーバは？ 「銀の弾丸」は無いが、現実的な選択肢は増えている。 1. スケールアップで対応（金の弾丸） • 「Fusion ioは甘え」でもいいじゃないか 2. 分散DB • Cassandra、HBase、MongoDBとかとか 3. すごいストレージサービスを使う • Amazon DynamoDBやGoogle BigQuery 39 3番目の選択肢の登場で できることが増えてきました
脱線： 分散DBにおけるCAP定理 40 • どれかが犠牲になる • 可用性 バルスできない • 一貫性 バルス書いた筈なのに 読めたり読めなかったり ※結果整合性 • ネットワーク分断耐性 バルス書いたのに サーバが死んで消えた 可用性 一貫性 ネットワーク 分断性 分かるようで分からない悪い例えです。
クラウド時代のサーバ設計 • Statelessサーバ • アプリを動かす • 台数でコントロールできる状態を保つ • Statefulサーバ • データを保存 • 気合い入れて頑張る 41
クラウド時代の脆弱性対応 • アプリケーションの脆弱性が圧倒的に多い • いかに迅速に動作確認するか 42
Blue-Green Deployment • もう1セット（Green）作って 古い方（Blue）を捨てよう！ 43 ｃ L B サーバー サーバー サーバー サーバー ③問題が無ければ 古い環境（Blue）を廃棄 ①新しいバージョン（Green）の 環境を構築 ②Greenに アクセス先を 切り替え DB 共通環境 脆弱性に限らず、一般的なテクニック 動作が怪しかったらすぐ戻せるのが最大の特長
万能じゃない • SSHとかStatefulサーバの脆弱性もある • きちんと脆弱性を評価して優先度を決めよう！ • 共通脆弱性評価システム：CVSS v2 https://www.ipa.go.jp/security/vuln/CVSS.html • 脆弱性チェックの自動化ツール：Vuls https://github.com/future-architect/vuls CVSSスコアで危険なものだけ通知できる 44
CVSS v2の基準 • 基本評価基準 (Base Metrics) • 脆弱性そのものの特性 • 機密性、完全性、可用性への影響、 攻撃のしやすさ（ネットワーク経由の攻撃可否など） • 現状評価基準 (Temporal Metrics) • 今どれぐらいやばいか • 環境評価基準 (Environmental Metrics) • 二次被害の度合いとかその他の影響範囲 45
CVSS実例 • CVE-2014-0160 Heartbleed • Base Score: 5.0 • CVE-2014-3566 POODLE • Base Score: 4.3 • CVE-2014-6271 Shellshock • Base Score: 10.0 • CVE-2015-0235 GHOST • Base Score: 6.8(RedHat) / 10.0(NVD) 46
クラウドの管理 • コントロールパネル • ブラウザで人がログイン • マウスでクリッククリッククリック…… • つらい • 人間は必ずミスをする • そもそも人の意志決定の余地は少ない 47
APIによるアクセス • サーバ環境をAPIで操作可能 • APIの認証情報（アクセスキー）を利用 • コントロールパネルとほぼ同じ操作が可能 • APIの利用 • APIを利用するライブラリやCLIコマンド • REST API • 自動処理が可能に！ 48 クラウドの最大の特長です！
Discussion #2 API操作ならではのリスクって？ • AWSみたいな大規模なクラウド環境 • いくらでもサーバが作れる（リミットは一応ある） • APIでさらに作りやすい • どんなリスクが新しく増えたのか考えてみよう！ 49
オフレコ 50
オフレコ 51
APIが万能である故の問題 • APIの認証情報があれば何でもできてしまう • 自動化プログラムとかにカジュアルに組み込みやすい • なにかされたことにすぐに気付きにくい 52 Two-Factor Appにもありましたが コードに直接認証情報を書いてはいけません
クラウドの管理 • 適切なアクセス制御 • 本当にその人に必要な作業しか実行させない • 最小権限の原則 • 操作内容の監査（記録） • 誰がその作業をしたのかを記録 • あやしい行動をチェックできる 53
最小権限の原則 • 情報セキュリティで最も重要な原則 • 必要最小限の権限だけを用意する • 例：アクセスキーの権限を最低限にする • 社外のIPアドレスから操作する権限は本当に必要？ • サンパウロでサーバ作成する権限は本当に必要？ • 1時間1400円もするサーバを作成する権限は(同上) 54 覚えて帰って欲しいキーワード その2
AWS Identity and Access Management （IAM） • アクセス権限を管理する仕組み • AWSは元々は1アカウント＝1認証情報（email/password) • ユーザやグループを作成して、権限を細かく割り当て可能 • より抽象化した「ロール」への割り当てもできる • アクセス元IPアドレスなども設定可能 55
AWS CloudTrail • 操作内容を記録する • Amazon S3（ストレージサービス）に保管 • 別のAWSアカウントにも送り込める • 外部の分析サービスとの連携も可能 56
ユーザの管理 • 何も考えないとすぐに崩壊 • システムの数だけID • システムの数だけパスワード • (ノ ゜Д゜)ノ ==== ┻━━┻ • 管理コスト • どこかでパスワードが一度漏洩すると全て変更してまわる • 入社時のアカウント作成（だいたい漏れる） • 退社時のアカウント削除（だいたい漏れる） 57
ID連携 • 社内のID基盤（ログインシステム）と連携 • ID基盤にログインできたユーザは、AWSのコンソールにその ままログイン可能（シングルサインオン） • ID基盤を作り込むことで、特定のプロジェクトに参加してい る正社員だけ連携、といったことも容易 • AWS IAMのユーザでは無く「ロール」に紐付けられる • ログインさせたユーザーの権限も設定できる 58
ID連携できないクラウドサービス • ID連携できないものも「把握」はしておく • むやみやたら閉め出すのもリスク • 便利なモノは禁止してもこっそり使われてしまう • 把握はしておき、退職者を棚卸し • Shadow IT • 管理されず把握もされていない外部サービス • 情報漏洩の流出源につながる • ダメ、ゼッタイ！ 59
オフレコ 60
オフレコ 61
オフレコ 62
オフレコ 63
オフレコ 64
ここまでのまとめ • クラウドコンピューティング • ペットから家畜へ、StatelessサーバとStatefulサーバ • APIの利用 • IDと権限の管理 65
IaaSの例 • 今回はこの二つを取り上げます • さくらのクラウド • Amazon Web Services （AWS） 66
基本的な機能は一緒 • サーバとネットワークを借りられる • CPU数、メモリ容量を指定可能 ※あらかじめ用意されたパターンから選択 • ディスク容量を指定可能 • 独自サブネットを持つ事が可能 • ファイアウォール • ロードバランサー 67
違う点 • AWS独自の「高レイヤー」なサービス 68
69 うはｗｗｗサービス多すぎｗｗｗｗｗｗ
違う点 • AWS独自の「高レイヤー」なサービス • 割り切ったサービスレベル • 一つのサーバが突然死ぬくらいは「障害」ではない • 冗長化の枠組みを用意してるから冗長化は利用者の責任 • さくらのクラウドは1台ごとの稼働率で判断 70 各社のSLAを比較してみると サービスの設計思想が見えて面白いですよ。
個人情報とかの保存 • パブリッククラウドって大丈夫？ 71
個人情報とかの保存 • パブリッククラウドって大丈夫？ • 大丈夫です！（※きちんとやれば） • ISO 27018 クラウド上での個人情報管理に関する規定 大手クラウド事業者がこぞっと取得 72
安全なデータの保存 • 権限管理 • データベース、データベースサーバへの接続権限の最小化 • 暗号化 • データベースの暗号化 • 通信路等の保護 • ネットワークレベルの分離 • 物理サーバ単位の専有化 • これらみなパブリッククラウドでもできます！ 73
「損失」の話、覚えてる？ • 1時間サービスが止まったときの被害はおいくら？ • 2016年3Qのゲーム事業売上高：306億円（四半期決算） （2016/04/01～2016/06/30：91日間） • 1時間あたりXXXXX万円（1分あたりYYYYY万円） 74
「損失」の話、覚えてる？ • 1時間サービスが止まったときの被害はおいくら？ • 2016年3Qのゲーム事業売上高：306億円（四半期決算） （2016/04/01～2016/06/30：91日間） • 1時間あたり1,401万円（1分あたり23万円） • ピークタイム（稼ぎ時） • 期間限定イベントのラストスパート • 月初（キャリア決済の限度額がクリア） • 年始めのおみくじ代わり 75
もうちょっと掘り下げてみよう 76
そもそも情報セキュリティ #とは • 機密性 Confidentiality • アクセスが許可された人だけが情報を見られること • 完全性 Integrity • 情報が改竄されず正確であること • 可用性 Availability • 必要な時に情報にアクセスできること • さっきの話はここしか見ていなかった 77 「情報セキュリティマネジメント」分野と インフラ領域は切っても切り離せません。
機密性が破られたときの損失 • 個人情報漏洩 • アメーバ会員数4000万人×500円＝200億円 （だいたい1年の利益分） • 会員流出に伴う課金売上減少 • アメブロPV減少に伴う広告収入源 • それ以後の機会損失 78
完全性が破られたときの損失 • ゲームのデータが大規模に改竄され信頼を失い サービス終了に追い込まれる • 本来売り上げていたはずの課金アイテムの売上減 • その他のゲームについての風評被害 • 人気あるゲームが出せなくなった事による社員の流出 79
リスク評価 • ある程度以上のビジネス継続リスクは許容できない • 対策コストが見合わないリスクは受容してもよい 80 突き詰めれば無限に対策ができてしまうが故に リスク評価で割り切ることが重要です。
小さな例も考えてみよう • スマホのリズムゲームでチートをされたが、巧妙にも 「非常に上手い人」と同レベルのスコアに留めている。 • スコアがその人本来の2倍になっていて、本来課金していた はずの回復アイテムの売り上げが半分に減っていた。 • ランキングを大きく崩すことはなく他者への影響がない • 売上全体額への影響はごく軽微 ……そんなの本当に調べる価値あるの？ 81
小さな例も考えてみよう • スマホのリズムゲームでチートをされたが、巧妙にも 「非常に上手い人」と同レベルのスコアに留めている。 • スコアがその人本来の2倍になっていて、本来課金していた はずの回復アイテムの売り上げが半分に減っていた。 • ランキングを大きく崩すことはなく他者への影響がない • 売上全体額への影響はごく軽微 ……そんなの本当に調べる価値あるの？ 82 たとえば「ざっくり上限制限」でもよい
リスク評価 • リスクの可視化 • 金額に落とすと定量的に評価できる • 失うものが少ないほど受容できるリスクが増える ※ 行き過ぎた結果が「サイバーノーガード戦法」 83 「サイバーノーガード戦法」、 そろそろ死語でしょうか……。
抑止防止検知回復 • 事前（予防） • 抑止 攻撃の機会を減らす • 防止 攻撃の被害を減らす • 事後 • 検知 攻撃されたことを発見する（ための枠組みをあらかじめ作る） • 回復 攻撃により低減したCIAを回復する（ための枠組みをあらかじめ作る） • 全部大事だよ • パッチあては「防止」でしかない 84
抑止・防止 • 攻撃の「機会」そのものを減らす • 対外的なアピール • エンドポイントを気軽に見せない • 攻撃の「被害」を減らす • 関係者の権限を管理する • 責務の分離 • 最小権限 85 いわゆる「割れ窓理論」とかも、 分かりやすい抑止策の一つですね。
検知 • 侵入検知 • → 検知トラック • 操作の監査 • AWS CloudTrail • 監査ログの分析 • 適切な意志決定者への報告、エスカレーション 86 検知できなければ、何の対策もできません。
回復 • 影響の封じ込め • 特に情報流出 • サービスの素早い復帰 • そのた各種事後報告 • プレスリリースとか • 個人情報流出被害の告知義務 87 ビジネスでは、事業の「回復」も重要です。 明日もご飯が食べられますように。
抑止防止検知回復おさらい • ID管理と監査を軸としたセキュリティ施策 • 抑止：ID管理と監査実施のアピール • 防止：適切なID管理と必要最小限の権限設定 • 検知：監査ログの分析、異常検知 • 回復：監査結果から影響範囲の確定、封じ込め対策 88
セキュリティはビジネスとの対立ではない • リスク・脆弱性の対応 • 例）クラウドでのデプロイ高速化→パッチ当て早くなる • ID管理と監査 • 裏で取られているだけで利便性は損ねない • むしろ全てAPI経由であることで記録が容易・確実に • 適切なセキュリティへの「投資」と捉えよう 89 ビジネス上のリスクを減らす(守る)だけでなく、 利益を増やす(攻める)ことにもなります。
演習 • クラウド体験 • クラウドのAPI操作 • IAM＋CloudTrailsでの監査 • LBを挟んだ無停止のパッチあて • クラウドっぽい活用 • RDSとS3でStatelessなサーバを作ってみる 90 単にサーバを作った消したでは意味が無いので、 APIで下のレベルで見てもらう演習です。
渡す環境 • AWSのIAMユーザ • ログイン用URL • ID • パスワード
注意事項 • AWSアカウントには制限が掛かっていません！ • 無料枠と表示されているt2.microだけ使ってください。 • こちらのアカウントは後ほど削除します。 クラウド破産こわい(((( ;ﾟДﾟ)))) AWSさん無料枠ありがとうございます！！！
ログインチェック • AWSのコンソールにログインできることを確認 • ログインしたら右上の「リージョン」を確認 • 「オレゴン」とかになっていたら、 クリックして「アジアパシフィック(東京)」に変更
アクセスキーの生成 • サービス一覧から「IAM」「Identity & Access Management」 • 新規ユーザの作成 • 適当な名前（yourname_cli とか） • 「ユーザーごとにアクセスキーを生成」に☑入っていることを確認 • 作成 • 「ユーザーのセキュリティ認証情報を表示」をクリック • アクセスキー IDとシークレットアクセスキーをメモ • 閉じる • 閉じる
EC2管理権限の割り当て • リストから今作ったユーザを開く • 「アクセス許可」タブを開く • 「管理ポリシー」の「ポリシーのアタッチ」をクリック • 「AmazonEC2FullAccess」を探して、□を■にして 右下「ポリシーのアタッチ」をクリック
AWS CLIのインストール • AWS配布ページからインストール • https://aws.amazon.com/jp/cli/ • Windowsならダウンロードしてインストール • Mac/Linuxなら、Pythonを入れてコマンドでインストール $ pip install awscli 96
AWS CLIに認証情報を登録 • コマンドプロンプトを開く • aws configure を実行 • 以下を入力 AWS Access Key ID [None]: ＜アクセスキーID＞ AWS Secret Access Key [None]:＜シークレットアクセスキー＞ Default region name [None]: ap-northeast-1 Default output format [None]: （そのまま改行）
動作確認 • うまく設定できていれば、 aws ec2 describe-instances でエラーが出ないはずです。
APIでサーバ作成 • SSHキーペアを登録 • 面倒なのでコンソールからで良いです。名前をメモること。 • セキュリティグループの変更 • こちらもコンソールから以下をdefaultに追加で開けましょう。 • TCP 80 FROM 0.0.0.0/0 • TCP 22 FROM 0.0.0.0/0 ※ 本来は接続元を制限するのが良いです。
APIでサーバ作成 • サーバを立てるサブネットのIDを検索 • SubnetIdを探す • APIでサーバ作成・起動 • エラーが出なければ、表示内容のInstanceIdを検索 「i-ffffffff」形式 100 aws ec2 run-instances --image-id ami-374db956 ⇒ --instance-type t2.micro --key-name ＜キーペア名＞ ⇒ --subnet-id ＜サブネットID＞ aws ec2 describe-subnets