狠狠撸

狠狠撸Share a Scribd company logo
クラウドは
セキュリティ的に
危ないのか
cloudpackが実践するセキュリティ対策から学ぶ
2015年9月17日
自己绍介
齊藤 愼仁
アイレット株式会社
cloudpack事業部
2013年8月入社
【ブログ】
ロードバランスすだちくん
http://blog.animereview.jp/
その前はHPCやってました
(ハイ?パフォーマンス?コンピューティング)
骋笔鲍いっぱいのせて
クラスタ
組んだり
するわけです
その前は2年くらい
ニートしてました
(24/365勤務)
(ずっとゲームしてた)
更にその前は
ドスパラの
法人部隊にいました
2009年に
GMOさんの
サーバー作った時の
記事
(ITmediaさん)
ある日シンジは
目覚めるのです
时代はクラウドじゃね?
そしてアイレットに
飛び込む
まず担当したのは
プロジェクトマネージャー
そして自社奥别产更新
からの客先常驻
もはや何でも屋
现在の肩书き
情报セキュリティ管理责任者
个人情报管理责任者
PCI DSS管理責任者
経歴とセキュリティの
シンクロ率が絶望的
きっかけは
新たな監査対応と
前任の退職
CTO鈴木
「シンジ君セキュリティやってー」
いいっすよー
1から現場で叩かれて
今に至ります
そして悟った
技術力(ITリテラシー)と
セキュリティリテラシーは
全くもって比例しない
セキュリティについて学ぶ
そもそもですね
セキュリティって
何のことですか?
例えばおうちのセキュリティ
かけてるとか
夜でも電気付けるとか
まぁいろいろありますよね
こーゆー場でいう
セキュリティというのは
だいたいが
情報セキュリティのこと
じゃあ
情報セキュリティって
なんのことですか
おもむろにググる
情報セキュリティは、
JIS Q 27002(すなわちISO/
IEC 27002)によって、
情報の机密性、完全性、
可用性を維持することと
定義されている。
(Wikipedia)
なんのことだか
よくわかりませんが
要するに
企業におけるセキュリティは
一定の基準が
必要ということです
自社で基準をつくるもよし
でも何から手を付けたら
よいのやら
そこで
外部の監査基準
いろんな基準があって
それぞれ役割が違います
プライバシーマーク
ご存じですよね?
ホームページに
こんなロゴ貼ってたりします
そもそも
プライバシーマークとは
なんなのか
個人情報について
適切な保護措置を講ずる
体制を整備している
事業者等を認定する制度
個人情報の取り扱いに
フォーカスしている制度
そして重要なのは
この制度は
「国内基準」
だということ
と
プライバシーに
特化しているということ
某社「ウチは
プライバシーマーク
取ってますので
セキュリティは
安心して下さい」
おー
安心だー
持ってない业者よりはね!
余谈ですが
シンジが業者選定するときに
プライバシーマークを
見つけたら
必ずやることがあります
そのマークは本物か
JIPDECの公式WEBで
確認出来ます
実際にそこそこいます
偽装してる会社さん
それほどまでに
プライバシーマークの
有効性はあるのか
あります
取引先から
「プライバシーマーク、
取得されてますよね?」
結構ある
シチュエーションです
プライバシーマークの
認知度は高く、
個人情報を取り扱ううえで
評価される
一定の基準となるわけです
これでセキュリティも万全
违いますよね
あくまで個人情報に
フォーカスしたわけです
じゃあ他にどんな基準が?
ISMS
ISO 27001:2014
ISMSとは
情報資産を守りながら、
リスク軽減を行いましょう
という適合性評価制度
プライバシーマークよりも
情報資産全般に関する
取り扱いになりましたね
そして重要なのは
国际基準
情報セキュリティとは何だ?
冒頭で軽く触れましたね
机密性
アクセスを認可された者だけが
情報に確実に
アクセスできること
完全性
情報資産が完全な
状態で保存され、
内容が正確であること
可用性
情報資産が必要になったとき、
利用できる状態にあること
特に监査で重要视されるのは
ISMSを
確立
導入
運用
監視
見直し
維持し
有効に機能させなさい
笔顿颁础サイクル
クラウト?はセキュリティ的に危ないのか
ISMSがあるかないかで
社内はかなり変わります
組織だった運用が必要
例えば
IS委員会(トップ集めて月例)
IS運用委員会(現場が2週に1回)
課題の管理
是正処置
報告
計画
PDCAを回す
クラウト?はセキュリティ的に危ないのか
运用が大事
ISMS取ってる会社だ!
これで安心だね!
ほんとに?
まだだ
まだ足りぬ
2015年09月15日
顧客情報の漏洩事件発生
クラウト?はセキュリティ的に危ないのか
流出の可能性がある情報
?お客様のお名前(漢字およびフリガナ)、
郵便番号、ご住所、電話番号
?メールアドレス
?パスワード
?クレジットカード情報(カード会員名、
ご住所、カード番号、有効期限)
?連名の方のお名前(漢字およびフリガナ)
?お子様(赤ちゃん)の性別?生年月日?
お名前(漢字およびフリガナ)?体重 ?フォト
カード用の画像とメッセージ
?商品お届け先様のお名前(漢字およびフリガナ)
郵便番号、ご住所、電話番号
ほぼ全部?
お客様情報流出の
可能性のある件数
当該サイト会員21,994件
(内クレジットカード情報あり
13,713件)
商品お届け先様を含む総件数
131,096件
ダダ漏れですわ
でもなんかぶっちゃけ
日常茶饭事な気がしません?
たぶんこう思ってるんだと
思うんです
たぶんウチは大丈夫
(根拠は无いけど)
その根拠を作る
良い基準があります
PCI DSS
Payment Card Industry
Data Security Standard
PCI DSS基準は
割と頻繁に更新されていて、
今はVersion 3.1です
PCI DSSとは何ぞや
クレジットカード情報や
取引情報を安全に守るために、
JCB、アメリカンエキスプレス、
Discover、マスターカード、
VISAの国際ペイメントブランド
5社が共同で策定した、
クレジット業界における
グローバルセキュリティ基準
そう、これも
国際規格
監査を受けるとよく分かる
ISMSとの違い
要求内容が
超具体的
例えば
実装するWebアプリに
脆弱性が無いか徹底的に
叩かれる
実装するインフラに
脆弱性が無いか
全設定項目を見られる
ミドルウェアなどに
パッチがリリースされたら、
1ヶ月以内に適用している事を
証明しなさい
カード会員データを扱う
システムは、
ほかのシステムと
完全に分離しなさい
などなど
大項目で
12の要件
全項目で
400項目以上の
監査事項
ISMSの場合は、
「こんな感じにしてください」
PCI DSSの場合は
「こうしなさい」
セキュティとは
こうあるべきだと
はっきりと明示している
PCI DSSは有効なのか?
有効です
はっきり言って、ユーザーが
「あ、PCI DSS持ってる、
安心~」
なんて言わないでしょう
やはり事业间取引
PCI DSSを持ってない
ところとは
手を組めませんね
(なんていうことも
あるでしょう)
ユーザーに直接的には
関係無いかもしれませんが
PCI DSS取得会社で
情報漏洩した場合
管理責任のあるカード会社に
求められる損害の補償の
義務が免責されます
基本的にPCI DSS取得時には
監査組織
及び
コンサル会社
の2社が絡みますので
事件発生から調査?段取り
(監査会社やコンサルへの
通報から初動まで)が早い
非常に強力な
セキュリティ基準
クレジットカードを
扱わない企業も
PCI DSSを取得するように
なってきています
その一方で课题も
1年更新なのですが
まーた400項目以上
総なめします
(バージョン上がると
増えることが多いです)
更に
1年間規定通りに
運用されているかまで
監査されます
要するに
継続が超大変
ベライゾンジャパン合同会社
の
2015年の調査報告書によると
PCI DSSを継続的に
準拠出来ている企業の割合は
たったの2割
PCI DSSは、2年以上
継続しているかどうかで
大きく見方が変わります
(シンジの見方)
PCI DSSが安定的に
運用出来ている会社は
安心だね!
いや、実は罠があります
PCI DSSは、
既存のシステムとは
分離したところで
システムを運用しなさいと
言っています
要するに
既存のシステムは监査対象外
監査範囲を
かなり限定的にできる
PCI DSS取ったし!
ウチの会社のセキュリティは
守られているね!
とは言えない
じゃあどうしたらいいんすか
セキュリティには基準が必要
その基準を
どの範囲で適用するかも重要
cloudpackの場合
AWSを運用構築している
それをお客様に提供している
要するにここが範囲
じゃあ础奥厂自身は?
クラウト?はセキュリティ的に危ないのか
なんかいっぱいあった
? PCI DSS レベル 1
? SOC 1/ ISAE 3402
? SOC 2
? SOC 3
? FIPS 140-2
? CSA
? FedRAMP (SM)
? DIACAP および FISMA
? ISO 27001
? MPAA
? 第 508 条/VPAT
? HIPAA
? DoD CSM レベル 1-2、3-5
? ISO 9001
? CJIS
? FERPA
? G-Cloud
? IT-Grundschutz
? IRAP(オーストラリア)
? MTCS Tier 3 Certi?cation
なるほどわからん
AWSが取ってるなら
cloudpackも取ってないと
お客様に安心をお届けできない
クラウドには
こういう考え方があります
共有责任モデル
クラウト?はセキュリティ的に危ないのか
安全なインフラは
提供するけど、
そのうえで動かす物は
知らんよー
ちょっと
突き放されている感も
ありますが、
そうではなくて
オンプレだったら
全部見なきゃ
いけなかったでしょ?
AWSにすればインフラ面は
任せてくれーい
ということなんですね
更に
OSの設定が甘いよー
セキュリティの設定が甘いよー
攻撃受けてるよー
(直してくれないとアカウン
トロックしちゃうぞ☆)
なんて教えてくれますけど
ロックされたら
システム止まるやん。。。
AWSが最高の
セキュリティ体制を
組んでくれていたとしても、
使う側がポンコツだと
全部ポンコツになるっていうー
じゃあAWSが取得している
厳しい監査基準のなかで、
使う側がこれやっておけば
最高みたいなの
なんかないんですかね
调べた
资料があった
特定非営利活動法人
日本セキュリティ監査協会
JASA
クラウト?はセキュリティ的に危ないのか
SOC 2
と
SOC 3
って一番上に書いてある
(ISMSが物足りないとか
書かれてますが)
よし、これ取ろう
SOC 2ってなに
米国公認会計士協会
(AICPA)が定めた
サービス組織(Service
Organization Control)の
統制に関わる
評価業務の仕組み
?
SOC 3の方が偉い?
(数字的に)
直接、监査法人に闻いてみた
まず
SOC 1
SOC 2?
SOC 3
があります
SOC1
財務評価
SOC 2
セキュリティ
可用性
処理のインテグリティ
機密保持
プライバシー
これのどれか1つ以上
SOC 3
SOC 2の内容を簡素にして
公開文章にしたもの
なるほど
役割が違うのか
今回はセキュリティに
フォーカスしたいので
SOC 2ですね!
いや実はもう1点ありまして
Type 1
と
Type 2
Type 1
ある1日を切り出して監査する
Type 2
3ヶ月以上の期間を切り出して
監査する
なるほど
目指すはSOC 2 Type 2
ということですね!
監査法人
「はい、ですが
まずはType 1から
取得されるのが
良いと思います」
よーし
じゃあ
SOC 2 Type 1だ!
そして
2年もの歳月がかかり
なんやかんややって
2015年8月31日
アイレット株式会社
cloudpack事業部
SOC2 Type1 受領
(セキュリティと可用性)
やって分かった
SOC 2 はこれまでの監査とは
まるで違う監査方法
SOC 2 Type1報告書には、
外部の監査法人から見た
ありのままの
全てが記述されます
丸裸です
提出した資料の数
数百ページ
システムの稼働状況を
何度も何度も
デモンストレーション
何が辛いって
ほんと全部、
事細かく突っ込まれるので
それが報告書に書かれて
お客様の目に触れると思うと
んー
ダメだ
1から全部作り直しだ
というわけで
業務で使う
WindowsやMacなどの
端末管理から始めた
1台1台調べて
管理台帳に記載して
確認して承認して
レビューして
无理
端末监视ソフトを入れよう
クラウト?はセキュリティ的に危ないのか
ライセンスも管理する
クラウト?はセキュリティ的に危ないのか
これは便利だ
でもサーバーが必要だ
よし
AWSで作ろう
こゆこと?
社内データが
インターネットを
経由するってこと?
ダメだ
そんなレポートじゃダメだ
大阪にも拠点があるし
これから増えるかもしれない
(これが可用性)
クラウト?はセキュリティ的に危ないのか
社内資産を閉域にする(閉ざす)
ことにこだわった
インターネットから隔離する
インターネットを使う会社
なので
全ての回線を専用線の
冗長構成にしました
(事業継続性?可用性)
物理はどうか
(ファシリティ)
? カードキーによる入退室管理
? 監視カメラ設置
? ビルそのものの?
耐震などのスペック確認
特に徹底した点は
電源設備
(事業継続性)
突然の停電はもちろんですが
オフィスビルには
年1回の法定点検
というのがあり
必ず停電時間が
発生します
cloudpackは
24時間365日の運用を
行います
停电などゆるさん
なので
3ライン
ひいた
虎ノ門ヒルズオフィスでは、
? 低層階用電力供給
? 高層階用電力供給
? 非常用発電機電力供給
この3ライン引いています
更に
UPSも数台設置しているので
万が一、2ライン死んで
発電機が動き始めるまでの
40秒間も耐えられます
これもセキュリティ
新しくチームも立ち上げました
CSIRT
颁厂滨搁罢ってご存じですか?
コンピュータセキュリティ
インシデント対応チーム
(Computer Security
Incident Response 罢别补尘)
定常的に脆弱性情報の収集を
行い、実際にソフトウェア脆
弱性が発見された場合には、
速やかにその影響の有無およ
び緊急度について判断し、ユー
ザー様のシステムを防護する
ために適切な対応を行います
ミドルウェアの脆弱性って
結構あるじゃないですか
それ突かれてお客様の
システムが被害受けたら
cloudpackも悲しい
ついでに
社内インフラも防御出来る
一石二鳥
そして
AWSを含む
クラウドサービスに
接続する際に必要な物
インターネット
アカウント名
パスワード
インターネットは仕方無い
でも暗号化されているか
PCI DSS 3.1基準に従えば、
SSL3.0はNG
TLS1.2限定
暗号化通信は
社内インフラも
全てそれに準拠する
そしてアカウント名と
パスワード
みなさん
クラウドサービス
使われていますか?
必ずと言っていいほど
アカウント名とパスワードが
必要ですよね
そのアカウント名と
パスワードが
某巨大掲示板とかに
書かれたら
アウトー
そこで多要素认証ですよね
2段階認証を有効にすれば
アカウント名や
パスワードが漏れていた
としても、2段階目の認証を
通さなければ
ログイン出来ない
そこでシンジは考えた
多要素認証しつつ
アカウント名と
パスワードが
無くなればいいんじゃないの
実装した
クラウト?はセキュリティ的に危ないのか
平たく言えば
シングルサインオンです
まずパソコンの
電源を入れます
翱厂起动します
ユーザー名と
パスワード聞かれます
シングルサインオンは、
ここで聞かれたユーザー名と
パスワードを使って、
クラウドサービスにログイン
しようとします
(細かく言うとちょっと
違いますがイメージです)
で、翱厂ログインしますよね
とあるクラウドサービスに
ログインしようとします
そうするとスマホに
通知が来ます
(多要素認証)
ようやくログイン
できるわけです
全てのアカウント名
パスワードは
統合認証サーバーで
管理されています
(Active Directory)
退社、休職、
インシデント発生時でも
統合認証サーバーの
アカウントを
ロックするだけで、
AWSはもちろん
全てのサービスへの
アクセスを食い止めます
PCI DSS基準で求められる
ログ監視?管理?レビュー
PCI DSS監査範囲だけだった
これらの作業を全体にして、
全てのネットワーク機器や
サーバーのログを
ログサーバーに収集して
定常的に分析?アラート
やたらとログインを
試みようとする端末を
特定したりします
これらは
全てのネットワークが
閉域網にあるからこそ
できる実装なのですが
社外から社内リソース見たい
ときはどうすりゃいいの?
営業が外出先で見積書を作る
かもしれない
構築運用が出先でお客様環境
にログインするかもしれない
そこで痴笔狈
OpenVPN含む、
会社が認めていない接続は
全て拒否
会社が導入しているVPNは、
「証明書認証方式」
を採用
なのでここにもアカウント名
とパスワードがありません
証明書のインストールは、
一定のワークフローをへて、
限られたメンバーのみが
直接インストールすることで
接続可能となります
そして重要なのは
一度インストールした証明書は、
再利用出来ないように
してあること
証明書をエクスポートして、
自宅のパソコンに
インストールしても、
認証が通らない
仕組みにしてあります
もちろん、
VPNサーバー側のログも
ログ収集サーバーに
送られていますから、
監視配下です
そして、人
年1回のセキュリティ教育
PCI DSS教育
入社時のセキュリティ教育
アプリケーション脆弱性教育
AWS公式トレーニング
などなどなど
それ以外にもあります
お客様への
サービス品質を保つ
(これもセキュリティ)
どんな作業が発生した場合に
誰が、いつ、何を、誰の承認を
得た後に、どうするか、結果ど
うなったか、問題があった場合
にどう切り戻すか
規定を起こし直して
徹底的に記録するようになった
そして
これらを取りまとめた文章を
公開するように言われる
クラウト?はセキュリティ的に危ないのか
セキュリティホワイトペーパー
を書いて
思ったことがあります
SOC 2のレポートも
お客様が読まれる読み物です
シンジにとっての
セキュリティとは
透明性
透明性こそが
サービス提供事業者に
求められる
最高のセキュリティだと
考えます
ウチはこんな
すごいWAF使ってますから~
とか
IPS/IDSだけじゃなく、
パケット監視もしてますから~
とか
アプリケーションはきちんと
脆弱性試験合格してますので~
だけじゃなくて
必要なのは
それを運営している会社の
透明性
何をしている会社で
何ができていて
何ができていないのか
これから
どうしようとしているのか
全てSOC 2に書かれます
ついでに監査人の
コメントまで入ります
ちなみに
市場はクラウドへ不安がある
その1位がセキュリティ
なぜか
なんだかよく分からないから
クラウドに限らず
利用するサービスは
そのリスクを評価して共有し
その上で利用することが大事
その評価を行うときに
外部監査の有効性が問われる
一定の基準を用いて評価され
それを公開していること
セキュリティは
多岐にわたります
自分で言うのもあれですが
SOC 2レポート取得できる
企業はそうそうないです
ISMSやPCI DSSなどを
うまく活用して
事業の透明性を高めること
それがクラウドを
売る側も使う側も
安心安全な
セキュリティに繋がると
信じています
完

More Related Content

クラウト?はセキュリティ的に危ないのか