SlideShare a Scribd company logo
1 of 49
正しく恐れるクラウドのセキュリティ
サイボウズ株式会社
執行役員 運用本部長
山本泰宇
自己紹介
▌サイボウズでの経歴
2005年 ガルーン2開発責任者
2006年 開発本部長
2008年 最高技術責任者
2010年 cybozu.com 開発責任者
2014年 運用本部長(現任)
▌運用本部
社内の情報システムを管理する情報システム部と、
自社クラウドサービスを管理するサービス運用部からなる組織
内容
▌近年のセキュリティ事件
▌脅威はどこにあるか
▌対策の基本方針
▌具体的な対策
サイボウズが実施する対策
お客様にお勧めする対策
▌まとめ
▌質疑応答
近年の
セキュリティ事件
アカウント乗っ取り事件の多発
▌Line, Twitter, Facebook 等々のア
カウント乗っ取りが多発
▌複数のサービスで共通のパスワードを
使っているユーザーが狙われる
「Stop! パスワード使いまわし」
https://www.jpcert.or.jp/pr/2014/pr140004.html
▌対策として、各社で二要素認証の実
装が進んだ
出典:http://matome.naver.jp/odai/2140265486676813001
サービスデスクにソーシャルエンジニアリング
▌2012年8月
▌Apple と Amazon に電話をか
けてアカウント乗っ取りに必要な情
報を入手
▌サービスデスクの管理システムに
目をつけたもの
出典:http://fladdict.net/blog/2012/08/icloud-hack.html
エドワード・スノーデン事件
▌2013年6月
▌アメリカ国家安全保障局の機密
情報が大量流出
▌関係者による内部犯行
▌データセンター間専用線の盗聴
等も明らかになった
出典:http://www.afpbb.com/articles/-/2950073?pid=10897395
年金機構からの大規模流出
▌2015年5月
▌125万件の個人情報が流出
▌ウィルス付きメールを開封
▌対応が遅れて被害が拡大
事前のルール整備が重要
出典:Wikipedia
SSL/TLS への相次ぐ攻撃
▌2011年9月 BEAST攻撃
▌2012年9月 CRIME攻撃
▌2014年9月 POODLE攻撃 (SSLv3 廃止)
▌2015年2月 RC4利用禁止 (RFC7465)
▌2015年10月 SHA-1 Freestart Collision
▌…
▌SSL/TLS を常に最新のものに
アップデートする体制が必要
出典:https://googleonlinesecurity.blogspot.jp/2014/10/this-poodle-bites-exploiting-ssl-30.html
基盤ソフトウェアの脆弱性
▌2014年4月 Struts
任意コード実行
▌2014年4月 OpenSSL
▌2014年9月 Bash
ShellShock
▌ゼロデイが相次いだ
脆弱性の改修方法が明確で
ない状態で攻撃される状況
▌Heartbleed は対策が遅れた
企業で情報流出の被害
公表が 4月7日
攻撃が 4月11日
▌対応できないサイトの一時閉鎖
というケースもあった
出典:http://heartbleed.com/
ascii.jp への DDoS 攻撃
▌2015年10月
▌Anonymous による DDoS
▌6日以上の期間アクセス不能
▌ASCII が狙われた理由が不明
出典:http://japanese.engadget.com/2015/10/22/ascii-jp-ddos-anonymous-it-ascii-jp/
出典:http://it.srad.jp/comments.pl?sid=670583&cid=2907221
脅威はどこにあるか
cybozu.com リスクマップ
サービスデスク
クラウド
オペレーター
サイボウズ株式会社
インターネット
cybozu.com データセンター
専用線網
お客様
ソーシャルエンジニアリング
盗聴
ウィルスメール DDoS
内部犯行
盗聴
窃盗
ゼロデイ
分析
▌攻撃経路
インターネット
専用線
サポートデスク(電話)
内部犯行・侵入
ユーザーサイド
▌すべての経路に攻撃の可能性はある
アクセスしやすい経路への攻撃は、種類・回数が多い
アクセスしにくい経路だからといって、攻撃されないわけではない
対策の基本方針
原則
▌インシデントは必ず発生する
ゼロデイ攻撃や DDoS の完全防御は困難
▌インシデント対策の目的は、被害の最小化
発生の予防、頻度の低下
発生時の早期検出、被害最小化
▌リスクは変動する
SHA-1 の危殆化等、外部環境の変化でリスクも変わる
常に情報を収集し、対策し続ける体制が必要
方針
▌インシデントの発生を前提に備える
CSIRT (Computer Security Incident Response Team)
侵入検知・防止システムや全操作履歴の保管
▌システムにアクセスできる人と権限を最小化する
多くの人がかかわるほど脆弱になる
プログラムにも必要以上の権限を与えない
▌常に情報を収集し、対策を更新する
新たな攻撃手法やゼロデイ脆弱性を日々監視
自社だけでなく、他社や善意の第三者と協力して対応
原則と方針
▌原則
インシデントは必ず発生する
インシデント対策の目的は、
被害の最小化
リスクは変動する
▌方針
インシデントの発生を前提に備える
システムにアクセスできる
人と権限を最小化する
常に情報を収集し、対策を更新する
サイボウズのセキュリティ体制
セキュリティ研究者
日本シーサート協議会
IPA・JPCERT/CC
セキュリティ監査会社
Cy-SIRT 事務局
ISMS 事務局
(内部統制)
セキュリティ委員会
運用本部
開発本部
Cy-SIRT
(CSIRT)
具体的な対策
対策カテゴリー
物理対策 ネットワーク対策
ソフトウェア対策 人的対策
監査 製品機能
物理:データセンター
▌FISC(金融情報システムセンター)
安全対策基準に準拠
▌設備
生体認証
マントラップ
監視カメラ
…
出典:http://itpro.nikkeibp.co.jp/atcl/column/14/346926/072200305/
物理:サイボウズオフィス
▌重要操作をする要員・端末を物理的に隔離
▌ネットワークも専用のものを用意
▌重要ゾーンは監視カメラで24時間監視・記録
▌重要ゾーンは写真撮影不可
物理:ストレージ暗号化
▌HDDには暗号化したデータを保存
aes-xts-plain64 + 512bit 鍵
▌サーバーやHDDを盗んでも、データの解読は不可能
▌ストレージ暗号化は順次展開中
2017年中には完了を予定
それまではHDDを物理破壊して廃棄
ネットワーク:インターネットからの隔離
▌重要業務端末はインターネットから隔離
Web はもちろん、メールも届かない
他の社内ネットワークからも切り離された
独立ネットワーク
オペレーターはインターネット用端末と
重要業務端末を使い分け
ネットワーク:SSL/TLS
▌Qualys SSL Labs A+
(最高評価)
▌最新のSSL/TLS技術を追求
 HTTP Strict Transport Security
(HSTS)
 Perfect Forward Secrecy (PFS)
 SHA-2 証明書
 …
出典:https://www.ssllabs.com/
ネットワーク:拠点間専用線の暗号化
▌通信データを IPSec で暗号化
▌専用線の盗聴を防止
ネットワーク:DDoS 防御
▌完全な DDoS 対策は困難
目をつけられないようにするのが一番という噂も…
▌バックボーン業者と連携して DDoS 防御機構を用意
一定の効果を期待
ネットワーク:ファイアウォール/WAF
▌通常のファイアウォールに加え、
HTTPトラフィックをモニタして攻撃をブロック可能
(Web Application Firewall / WAF)
▌自社製 L7 ロードバランサーにてルール追加
▌Struts の脆弱性対応時に活用
ソフトウェア:緊急更新
▌毎日脆弱性・ゼロデイ情報を確認
JPCERT/CC 等数多くの情報ソースを参照
▌緊急性の高い脆弱性の場合、即座にシステムを更新
ベンダのパッチが間に合わない場合、
独自にパッチを展開する体制を整備
アプライアンスサーバー等のブラックボックスはほとんどない
▌実績
OpenSSL Heartbleed は認知から2時間半で対応完了
Struts も認知から2時間半で前述の暫定対応
その後も新たな攻撃パターンがでるたびに即時更新
ソフトウェア:定期更新
▌緊急性が低い脆弱性も確実に潰すため、
毎月定期的にパッチを適用
▌製品が依存している各種ライブラリも、
定期的に更新
ソフトウェア:強制アクセス制御
▌強制アクセス制御とは:
明示的な許可のない動作以外禁止するOSの仕組み
例えば、許可されないファイルは絶対に開けない
▌ソフトウェアの未知の不具合に対して極めて有効
未知の不具合をつくゼロデイ攻撃を防止できる
侵入検知・防止システム(IDS/IPS)としても働く
▌インターネットから入るデータを扱うソフトウェアに対して
強制アクセス制御を適用している
ソフトウェア:外部 JavaScript の禁止
▌外部 JavaScript の埋め込みは本質的に危険
代表例:Google Analytics
悪用されると、データを不正に操作可能
▌インターネット接続の規制が厳しい会社ではブロックされる
製品が依存していると不具合になる
同様の理由で CDN も使いずらい
▌ログインが必要なWebサイトでは一切埋め込みを禁止
人:内部犯行の特徴
▌内部不正者のタイプ ▌期待できる対策への回答
タイプ 割合
一般従業員 85%
財務・会計スタッフ 22%
経営幹部・上級管理職 11%
ヘルプデスク 4%
システム管理者 3%
ソフトウェア開発者 2%
不明・その他 2%
出典:IPA 「組織内部者の不正行為によるインシデント調査」報告書
対策 割合
操作の証拠が残る 54.2%
アクセスが監視される 37.5%
同僚が処罰されたことがある 36.2%
IDやパスワードの厳格管理 31.6%
罰則規定の強化 31.4%
管理者以外の操作が不能 29.2%
… …
人:アクセス権限の最小化
▌データセンターへのアクセスはごく少数の正社員のみ
▌サポート用の権限も細分化して必要最小限を付与
「試用期限の延長のみ」など
人:全操作履歴の保存
▌オペレーターの操作はすべて記録・保存
内部犯行以外でも、オペミスの確認などに活用
注:イメージです
監査:外部業者による定期セキュリティ監査
▌サイバーディフェンス研究所様に
定期的に製品・ネットワークのセ
キュリティ検査を依頼
出典:https://www.cyberdefense.jp/client/cybozu.html
監査:ISMS 認証
▌ISMS (ISO/IEC
27001:2013) 認証を取得
▌毎年、認証機関の監査あり
出典:http://www.isms.jipdec.or.jp/lst/ind/CR_IS_x0020_577142.html
監査:情報公開
▌詳細な情報を Web で公開
https://www.cybozu.com/jp/productsecurity/
▌コンテンツ
 脆弱性情報
 セキュリティチェックシート
 第三者監査結果
お客様に
お勧めする対策
製品機能:サブドメインとログイン画面
▌お客様毎に異なるサブドメイン
Same-Origin-Policy
IPアドレス制限
ログイン画面のカスタマイズ
▌ログイン画面
画像・会社名を変更可能
フィッシングサイト対策にどうぞ
製品機能:ストアでできる設定
製品機能:ストアでできる設定
▌IPアドレス制限
特定のIPアドレス以外からのアクセスを禁止
BASIC認証やセキュアアクセスと組み合わせ可能
▌Basic認証
全ユーザーで共通するパスワードを設定
退職者がでる都度変更するべき
▌セキュアアクセス(有償オプション)
ユーザーごとのクライアント証明書を発行
いつでも失効・再発行可能なので運用が楽
製品機能:パスワードポリシーとアカウントロックアウト
▌お勧め設定
パスワードは10文字以上
16文字以上なら一層安心
アカウントロックアウトを有効に
ロックアウト解除は15分
▌パスワードの使いまわしは厳禁!
製品機能:監査ログ
▌重要レベルのログをメール送信
アカウントロックアウト等にいち
早く気づける
▌ログが多い場合、書き出し形式を
XLSX から CSV (UTF-8)に
Excel で開けないので…
まとめ
まとめ
▌クラウドシステムには様々なセキュリティリスクがある
アカウント乗っ取り、盗聴、ウィルス、DDoS、etc.
▌cybozu.com では原則と基本方針を定めて対策している
方針に基づき、各種対策を導入
完璧なセキュリティは存在しないと考え、日々改善
▌お客様が設定可能なセキュリティオプション
サブドメインのアクセス制御
ユーザーのパスワード管理
再掲:原則と方針
▌原則
インシデントは必ず発生する
インシデント対策の目的は、
被害の最小化
リスクは変動する
▌方針
インシデントの発生を前提に備える
システムにアクセスできる
人と権限を最小化する
常に情報を収集し、対策を更新する
質疑応答

More Related Content

What's hot

[AWSマイスターシリーズ] AWS Client Side SDK -Android,iOS & JavaScript-
[AWSマイスターシリーズ] AWS Client Side SDK -Android,iOS & JavaScript-[AWSマイスターシリーズ] AWS Client Side SDK -Android,iOS & JavaScript-
[AWSマイスターシリーズ] AWS Client Side SDK -Android,iOS & JavaScript-
Amazon Web Services Japan
 
CloudFront最近の事例と間違った使い方
CloudFront最近の事例と間違った使い方CloudFront最近の事例と間違った使い方
CloudFront最近の事例と間違った使い方
Hirokazu Ouchi
 

What's hot (20)

Infrastructure as Code (IaC) 談義 2022
Infrastructure as Code (IaC) 談義 2022Infrastructure as Code (IaC) 談義 2022
Infrastructure as Code (IaC) 談義 2022
 
俺と Active Storage + CloudFront
俺と Active Storage + CloudFront俺と Active Storage + CloudFront
俺と Active Storage + CloudFront
 
インストールしてみたWindows Server 2019 on VirtualBox
インストールしてみたWindows Server 2019 on VirtualBoxインストールしてみたWindows Server 2019 on VirtualBox
インストールしてみたWindows Server 2019 on VirtualBox
 
AWSでDockerを扱うためのベストプラクティス
AWSでDockerを扱うためのベストプラクティスAWSでDockerを扱うためのベストプラクティス
AWSでDockerを扱うためのベストプラクティス
 
[AWSマイスターシリーズ] AWS Client Side SDK -Android,iOS & JavaScript-
[AWSマイスターシリーズ] AWS Client Side SDK -Android,iOS & JavaScript-[AWSマイスターシリーズ] AWS Client Side SDK -Android,iOS & JavaScript-
[AWSマイスターシリーズ] AWS Client Side SDK -Android,iOS & JavaScript-
 
20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13
20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #1320210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13
20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13
 
DevOpsにおけるAnsibleの立ち位置と使い所
DevOpsにおけるAnsibleの立ち位置と使い所DevOpsにおけるAnsibleの立ち位置と使い所
DevOpsにおけるAnsibleの立ち位置と使い所
 
ベロシティを上手く使って 技術的負債を計画的に解消する
ベロシティを上手く使って 技術的負債を計画的に解消するベロシティを上手く使って 技術的負債を計画的に解消する
ベロシティを上手く使って 技術的負債を計画的に解消する
 
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
 
プロトコルから見るID連携
プロトコルから見るID連携プロトコルから見るID連携
プロトコルから見るID連携
 
AWS SDK for Android and iOS
AWS SDK for Android and iOSAWS SDK for Android and iOS
AWS SDK for Android and iOS
 
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くかDDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
 
なぜOpenID Connectが必要となったのか、その歴史的背景
なぜOpenID Connectが必要となったのか、その歴史的背景なぜOpenID Connectが必要となったのか、その歴史的背景
なぜOpenID Connectが必要となったのか、その歴史的背景
 
私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由
 
AWS Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeD...
AWS Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeD...AWS Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeD...
AWS Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeD...
 
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチレガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
 
JJUG CCC リクルートの Java に対する取り組み
JJUG CCC リクルートの Java に対する取り組みJJUG CCC リクルートの Java に対する取り組み
JJUG CCC リクルートの Java に対する取り組み
 
ドメイン駆動設計 分析しながら設計する
ドメイン駆動設計 分析しながら設計するドメイン駆動設計 分析しながら設計する
ドメイン駆動設計 分析しながら設計する
 
CloudFront最近の事例と間違った使い方
CloudFront最近の事例と間違った使い方CloudFront最近の事例と間違った使い方
CloudFront最近の事例と間違った使い方
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
 

Similar to 正しく恐れるクラウドのセキュリティ

お客様からのセキュリティチェックを乗り越えるための SaaS のアプローチ.pptx
お客様からのセキュリティチェックを乗り越えるための SaaS のアプローチ.pptxお客様からのセキュリティチェックを乗り越えるための SaaS のアプローチ.pptx
お客様からのセキュリティチェックを乗り越えるための SaaS のアプローチ.pptx
mkoda
 

Similar to 正しく恐れるクラウドのセキュリティ (20)

セキュリティ対策は経営課題 - 情報セキュリティリスクに備える Cy-SIRT の軌跡 -
セキュリティ対策は経営課題 - 情報セキュリティリスクに備える Cy-SIRT の軌跡 -セキュリティ対策は経営課題 - 情報セキュリティリスクに備える Cy-SIRT の軌跡 -
セキュリティ対策は経営課題 - 情報セキュリティリスクに備える Cy-SIRT の軌跡 -
 
スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:
スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:
スタートアップのCEOもおさえておきたい、ITインフラのセキュリティ対策 先生:
 
【スカイアーチ】Webサイトを脆弱性攻撃から守る
【スカイアーチ】Webサイトを脆弱性攻撃から守る【スカイアーチ】Webサイトを脆弱性攻撃から守る
【スカイアーチ】Webサイトを脆弱性攻撃から守る
 
DVWAで爆上げWebAppセキュリティスキル@shunaroo
DVWAで爆上げWebAppセキュリティスキル@shunarooDVWAで爆上げWebAppセキュリティスキル@shunaroo
DVWAで爆上げWebAppセキュリティスキル@shunaroo
 
2019 1102 jaws_festa_f-secure10min_lt_slideshare
2019 1102 jaws_festa_f-secure10min_lt_slideshare2019 1102 jaws_festa_f-secure10min_lt_slideshare
2019 1102 jaws_festa_f-secure10min_lt_slideshare
 
2020 0925 sfdc_live_it_f-secure_cloud_security
2020 0925 sfdc_live_it_f-secure_cloud_security2020 0925 sfdc_live_it_f-secure_cloud_security
2020 0925 sfdc_live_it_f-secure_cloud_security
 
2020 0910 f-secure_remote_work_and_cloud_security
2020 0910 f-secure_remote_work_and_cloud_security2020 0910 f-secure_remote_work_and_cloud_security
2020 0910 f-secure_remote_work_and_cloud_security
 
2020_0625_Cloud and Salesforce Security_Security Consulting_pre_version
2020_0625_Cloud and Salesforce Security_Security Consulting_pre_version2020_0625_Cloud and Salesforce Security_Security Consulting_pre_version
2020_0625_Cloud and Salesforce Security_Security Consulting_pre_version
 
OWASP ASVS と Cheat Sheet シリーズ (日本語版) のご紹介 (OSC2016Hokkaido)
OWASP ASVS と Cheat Sheet シリーズ (日本語版) のご紹介 (OSC2016Hokkaido)OWASP ASVS と Cheat Sheet シリーズ (日本語版) のご紹介 (OSC2016Hokkaido)
OWASP ASVS と Cheat Sheet シリーズ (日本語版) のご紹介 (OSC2016Hokkaido)
 
Msセミナー20170830 slideshare
Msセミナー20170830 slideshareMsセミナー20170830 slideshare
Msセミナー20170830 slideshare
 
[data security showcase Sapporo 2015] D23:ホームページ改ざんや情報流出からWEBを守る! ~WAF「SiteGu...
[data security showcase Sapporo 2015] D23:ホームページ改ざんや情報流出からWEBを守る! ~WAF「SiteGu...[data security showcase Sapporo 2015] D23:ホームページ改ざんや情報流出からWEBを守る! ~WAF「SiteGu...
[data security showcase Sapporo 2015] D23:ホームページ改ざんや情報流出からWEBを守る! ~WAF「SiteGu...
 
Stackdriver を利用した実戦的なサーバ監視・運用方法
Stackdriver を利用した実戦的なサーバ監視・運用方法Stackdriver を利用した実戦的なサーバ監視・運用方法
Stackdriver を利用した実戦的なサーバ監視・運用方法
 
Stackdriver を利用した実戦的なサーバ監視・運用方法
Stackdriver を利用した実戦的なサーバ監視・運用方法Stackdriver を利用した実戦的なサーバ監視・運用方法
Stackdriver を利用した実戦的なサーバ監視・運用方法
 
2019 0731 f-secure_ali_eater_tokyo12_slideshare
2019 0731 f-secure_ali_eater_tokyo12_slideshare2019 0731 f-secure_ali_eater_tokyo12_slideshare
2019 0731 f-secure_ali_eater_tokyo12_slideshare
 
クラウドセキュリティ基礎 #seccamp
クラウドセキュリティ基礎 #seccampクラウドセキュリティ基礎 #seccamp
クラウドセキュリティ基礎 #seccamp
 
Security measures
Security measuresSecurity measures
Security measures
 
2019 1009 f-secure_ali_eater_tokyo13_slideshare
2019 1009 f-secure_ali_eater_tokyo13_slideshare2019 1009 f-secure_ali_eater_tokyo13_slideshare
2019 1009 f-secure_ali_eater_tokyo13_slideshare
 
20191013_Wolf and Seven Little Goats -Serverless Fairy Tales-
20191013_Wolf and Seven Little Goats  -Serverless Fairy Tales-20191013_Wolf and Seven Little Goats  -Serverless Fairy Tales-
20191013_Wolf and Seven Little Goats -Serverless Fairy Tales-
 
お客様からのセキュリティチェックを乗り越えるための SaaS のアプローチ.pptx
お客様からのセキュリティチェックを乗り越えるための SaaS のアプローチ.pptxお客様からのセキュリティチェックを乗り越えるための SaaS のアプローチ.pptx
お客様からのセキュリティチェックを乗り越えるための SaaS のアプローチ.pptx
 
”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版)
”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版)”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版)
”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版)
 

More from ymmt (6)

Cybozu Meetup #2 SRE
Cybozu Meetup #2 SRECybozu Meetup #2 SRE
Cybozu Meetup #2 SRE
 
Cybozu Meetup Osaka #2 SRE
Cybozu Meetup Osaka #2 SRECybozu Meetup Osaka #2 SRE
Cybozu Meetup Osaka #2 SRE
 
アーキテクトになるには
アーキテクトになるにはアーキテクトになるには
アーキテクトになるには
 
rebaseにまつわる3つの誤解
rebaseにまつわる3つの誤解rebaseにまつわる3つの誤解
rebaseにまつわる3つの誤解
 
Git & GitHub & kintone でウルトラハッピー!
Git & GitHub & kintone でウルトラハッピー!Git & GitHub & kintone でウルトラハッピー!
Git & GitHub & kintone でウルトラハッピー!
 
プログラマ人生論
プログラマ人生論プログラマ人生論
プログラマ人生論
 

正しく恐れるクラウドのセキュリティ

Editor's Notes

  1. サイボウズで運用本部長を務めている山本と申します。 本日は「正しく恐れるクラウドのセキュリティ」と題して、cybozu.comなどのクラウドシステムを安全に運用する方法を解説いたします。
  2. まず初めに自己紹介から。 サイボウズでは10年以上働いております。開発者とマネージャーの両方を務めてきましたが、 昨年からは運用本部長に就いています。こちらはいわゆる情シスと、自社クラウドサービスの運用とを任されています。 私は情シス部長も兼務しておりますので、クラウドサービスの提供側と利用者側の両面でセキュリティ対策をしています。
  3. 今日お話しする内容はこちらです。 まず、近年のセキュリティ事件についていくつか事例をご紹介します。 次に、cybozu.comのシステムのどこにリスクがあるかを分析し、 セキュリティ対策の原則と基本方針を解説します。 その後、具体的な対策を紹介したあと、お客様に気を付けていただきたいこともお話しします。 最後に時間があれば、質疑応答も受け付けたいと思います。
  4. では、近年のセキュリティ事件を振り返ってみましょう。
  5. まずは日々頻発しているアカウントの乗っ取りが挙げられます。 ・手口としては複数のサービスで。。。 ・去年は JPCERTにて Stop ...キャンペーンも実施されていました。 ・対策として... のですが、二要素認証を有効にしなければ効果はないので、安全に使うには必ず有効にしましょう。  サイボウズでも業務利用するクラウドサービスでは二要素認証を利用するルールになっています。
  6. 次に紹介するのは、Appleと Amazonに電話をかけて、Gmailのアカウントを乗っ取り、 最終的には T witter のアカウントを乗っ取った手口です。サービスデスクの本人確認 が簡素なのをついたソーシャルエンジニアリングという手法ですね。 サービスデスクというのは多少のシステム権限を持つものなので、こういう攻撃にも 注意が必要ということです。
  7. 次は 2013年に発生したエドワード・スノーデン事件です。 世界的な大事件でしたが、アメリカの政府機関である NSA職員による内部犯行で 大量の機密データが流出したものです。 政府機関といえど、内部犯行の抑止は難しいことを示したと。 また、NSAが Googleのデータセンター間の専用線を盗聴していることも 明らかになったりしました。
  8. お次は日本の、年金機構からの個人情報流出事件です。 こちらは外部からのウィルス付きメールを開封して、対応が遅れるまに被害が拡大したものです。 今はメールも感染源としては、ポピュラーな手段になっていますね。
  9. 次は SSL/TLSというプロトコルへの攻撃です。SSLというのは、インターネットの通信を安全にする 仕組みですが、これが破れると通信内容が盗聴されたりします。 2011年9月のBEAST攻撃や、2014年9月のPOODLE攻撃など、次々と新たな攻撃が 考え出されてきました。そのたびにブラウザやWebサーバーを更新して対策してくる 必要があったわけです。
  10. 広く使われているオープンソースソフトウェアの脆弱性も攻撃に利用されています。 2014年にはJavaのミドルウェアのStrutsや SSL実装のOpenSSL、あるいはBash といったソフトウェアに重大な脆弱性がみつかっています。これらは改修方法が広まる前に 攻撃が開始される、いわゆるゼロデイという状況が相次ぎました。 ゼロデイには一刻も早い対応が必要になるわけですが、OpenSSL の Hearbleed 脆弱性 の際は、速やかに対応できなかった一部の企業で情報漏えいの被害が出ました。 ・4日間対策できなかったら被害を受けたと ・対策ができない場合、サイトを一時閉鎖するところもありました
  11. 最後の事例ですが、これはつい先日、ascii.jpというサイトが DDoS攻撃というのを 受けて6日間つながらなくなっています。その後毎日新聞や東京オリンピックのサイトも 同じ攻撃を受けています。 DDoSというのは、世界中のコンピューターを悪用して過剰な通信で狙った Webサイトをつながらなくするという攻撃です。性質が悪いのは、しかけるのは 中学生でもできると言われているんですが、防ぐのは大変難しいんですね。 asciiの場合、anonymousが狙ったという話がありますが、狙う動機も曖昧で、 対応は非常に難しいですね。
  12. さて、一通り事例を見てきましたが、クラウドサービスにはどのような脅威があるかまとめてみます。
  13. これは cybozu.comのシステムとその周辺を図にしたものです。 cybozu.comのデータセンターがあって、それに専用線でつながっている サイボウズのオフィスや、インターネットでつながっているお客様のオフィス があります。これを悪い人が攻撃してきます。 まず最初に、インターネットというのはオープンなネットワークですから、盗聴が容易です。 なんの対策もないと、通信が盗聴されると。また先ほど解説した DDoSで cybozu.com につながらないようにしたり、ウィルスメールをサイボウズの社員に送って侵入したり、 サービスデスクに電話をかけてだましたり、あるいは政府みたいなところですと専用線を 盗聴したり、またサーバーや廃棄したハードディスクを盗んだり、ゼロデイな脆弱性を ついて侵入したりする可能性があります。 また、サイボウズの社員の内部犯行や、あるいはお客様での内部犯行もあるかもしれません。
  14. これらを分析しますと、攻撃経路はこのようにいろいろあるわけです。 どの経路も攻撃される可能性はありますが、アクセスしやすい経路、まあ インターネットですね、は攻撃の種類や回数が多いといえます。
  15. 以上の事例や分析を踏まえまして、サイボウズではセキュリティ対策の原則と方針を定めています。
  16. まず原則ですが、大きく3つあります。 一つ目が「インシデントは必ず...」なぜかというと、ゼロデイやDDoS のように完全に防御するのは困難なものがあるからです。 二つ目が「...」完全に防ぐってことではなく、発生を前提に、頻度を減らしたり早期に検出したりすることで、被害を最小化すると。 3つ目が「...」事例で紹介したように、次々と新しい攻撃がでてきます。なので情報を収集して、対策を更新し続ける必要があると。
  17. この原則を踏まえた対策の基本方針がこの3つとなります。 一つ目が「... 」
  18. この原則と方針をまとめると、こうなります。原則に対応して、方針が決まっているのが分かるかと思います。
  19. で、実際にセキュリティ対策を検討したり実施したりする体制はこうなっています。 まずセキュリティ委員会というのがあって、全社的なセキュリティルールを議論する場となっています。 次に、サイボウズのCSIRTなので、Cy-SIRTというのですが、Cy-SIRTという組織があります。 Cy-SIRTは対外的な窓口になっていて、 社外のセキュリティ関係機関や、研究者の人と日ごろから 情報交換しています。また、ISMSというセキュリティの 認証のために、ISMS事務局があり、定期的に 監査を受けています。これに開発本部や運用本部が加わって、 全社的なセキュリティ体制となります。
  20. それでは、具体的な対策をいくつか紹介していきます。
  21. 対策もばらばら紹介するとわかりにくいので、6つのカテゴリーにわけて紹介していきます。 まず物理対策、これは窃盗や物理的な侵入の対策ですね。 次にネットワークの盗聴などの対策、ソフトウェアの脆弱性などの対策、 内部犯行などへの対策、セキュリティがしっかりしているかの監査、 そして製品機能での対策です。
  22. ここまでがサイボウズの対策ですが、ここからはお客様にお勧めする対策となります。
  23. 最後になりますが、監査ログという機能を紹介します。
  24. 本当に最後になりますが、ぜひこれは覚えて帰っていただきたいということで、原則と方針について再掲します。 この原則と方針はサイボウズに限らず、広く通用する考えだと思いますので、心にとめていただければ幸いです。 以上となります。
  25. それでは、残りの時間でご質問あれば回答したいと思います。 ご質問ある方は挙手を願います。