こんにちは、ひろかずです。
４回目となるDeep Security User Nightに行ってきましたので、一筆書きます。
- 例によってのリアルタイム執筆なので、抜け漏れ表記ゆれはご容赦ください。
会場は、前回に引き続きHAPON新宿
ビアバッシュ形式でプシュッとしてからの開始です。
会場はほぼ満席。温まっていい感じです。
Session1 NTTドコモのクラウド利用とDSM共通基盤
守屋さん (株式会社NTTドコモ)
社内でDSM共通基盤を作って、運用している。
ドコモのクラウド利用
- AWS300アカウント
- AWSは、商用、評価検証使ってる
- 分野もWebから、分析/機械学習、モバイルアプリ・ゲーム等多岐にわたる
- Azureは、検証用途で主に使ってる
クラウドを利用する理由
- 早く試せる
- ダメならすぐ止められる
- 時間を買える
運用でボトルネックは作らない
- アカウントや、サブスクリプションはプロジェクト毎に独立
セキュリティの壁
- ドコモ社内では280項目のセキュリティチェックをクリアする必要がある。
守屋さんの部署はクラウド利用を統括する中で、ガイドラインやデザインパターンなどのノウハウ収集、ツール類を作っている
最終的にドコモクラウドパッケージに落とし込んでいる
DSの導入背景
- WAF、IDS/IPS、改ざん検知、ウィルス対策の要件がある
- 1製品で対応できる
- ホスト型なので、ネットワーク型のようにセキュリティ機器の障害によるサービス影響がない
- AS対応もできるのはいい
- リファレンスも充実
- クラウドのベストプラクティスにフィットしている
DSMの選択肢
- DSaaSとDSMのパターンがある
DSaaS
- サーバ側の構築運用保守が不要
- 最新DSMが使える
- 圧倒的に楽
DSM
- オンプレ、クラウドにマネージャを構築
- コントロールできるが、ちょっと面倒
DSaaSを使いたいが、ドコモ的に壁がある
- そもそもSaaS型は厳しい
- コントロールが効かない（ログ保存期間13週だったが、2017年5月から4週に短縮）
- 社内の事情により断念
プロジェクトによりサブスクリプションを独立する要件がある
答えとしては、自前のDSMをマルチテナントとして構築して、DSMとDSaaSのいいとこ取りをする。
- インターネット経由については、暗号化が適切であれば、OK。
- NAT経由でもOKなので問題はなかった。
- プロジェクト数は20,管理台数は数百台規模
導入効果
- プロジェクトによっては、数十万/つきの運用費削減
- スタートアッププロジェクトで予算がなくても対応できるようになった。
- DSの運用ノウハウが集約
気をつけていること
- マルチテナントのDSMを社内SaaSとして運用
- DSM共通基盤をボトルネックにならないようにする
メリット
- 各プロジェクトからセキュリティ運用ノウハウを収集
- APIによる運用
Session2 家電のクラウドとセキュリティのお話
音川さん (シャープ株式会社)
ロボホンのリリースでトレンドマイクロ南原さんにお世話になったとのこと。
今日の話は家電のためのクラウドの話をします。
セキュリティは大事なので、ちょっとだけDSの話
家電がクラウドに繋がるって、IoT
AIoT（造語）
- 家電をクラウドに接続して人工知能化
- もっとヒトと寄り添う存在に
- ロボホン、COCORO+（家電を暮らしのパートナーに変えていくプロジェクト）
実はシャープさんは、10年前からIoT？をやっている
- Aquosオーナーズラウンジ
シャープでは家電のサーバは全部クラウド！（AWS）に持っていってる。
- が、ITは違う
- ITの人たちは、オンプレの視点でクラウドを見るので日々戦い
家電クラウドの目的
- 家電をクラウドで進化
- 家電にコンテンツ供給（レシピの配信etc）
- 家電とサービスの融合（ヘルシオに広告配信：料理ができそうになったら広告表示：引き合い多数）
家電製品は単体でやれることはなくなった（省エネ競争）
家電クラウドの特性
- オープンな環境上のクローズな環境（セキュリティ的にフルオープンはない）
- クライアントのアップデートは期待できない
- 長期稼働の要求（10年後どうなるか）
家電のクラウドシステム
- 家電アダプタ経由でHTTP+ECHONET Lite(HEMS対応)で通信 → データベースに格納
- Web Socketを使ってプッシュ通知
家電のクラウドのセキュリティはとても大事。
- Miraiのようなものが悪さをしないようにしないといけない。
- エアコンの操作は命に関わるかも
- 入念な脆弱性テストを実施
- 加えてDeepSecurity
シャープのDeepSecurityの利用
クラウドセキュリティの社内の標準ツール
- 検出モード(サービス通信を誤検知しないようにチューニング)
- 防御モード(チューニングを経て攻撃通信を遮断する)
セキュリティ事故の損失
- 経済的損失
- ブランドに対する損失
- 労働力の損失
Webサイトの改ざんは、依然深刻。
- 対応日数は、11日以上かかることが３割
事故を防ぐことが重要
だが、事故が起きた時の対応はもっと重要
Auto Healingシステム
- 攻撃の未意味化
- DeepSecurityで検知した変更をトリガーに、gitから短時間で復帰させる。
- メンテナンス作業の効率化という副次的効果も（ロックファイル運用で、運用負荷を軽減）
LT枠1 CloudFormation Template for Amazon ECS with Deep Security Agent（俺達のCloud Formation）
姜さん (トレンドマイクロ株式会社)
サブタイトル：女神は微笑むのか
今日やること
CloudFormationをつかってスタック２つ
- VPCの上にECSを起動して、ASグループに参加させる
- ECSクラスタサービスを起動して、ALBに参加させる
実機確認では、女神画像が表示されるとのこと（ハズレは別画像）
DS10の機能をちょっとだけ使う
デモ（会場でお楽しみ下さい！）
DS10の部分
- Container内にダウンロードされたファイルのウィルス検知ができるよ！使ってね！
- 今日の内容は、Webで公開予定！「trendmicro aws microsite」で検索！
LT枠2 One problem and one solution when using DSaaS on the cloud.
工藤さん (アイレット株式会社)
英語書くとslideshareのViewが上げる
テーマ:出口対策
Outboundは制限するのだけど、DSaaSを使うのに80/443フルオープンが必要
クラウド環境ではIP/portベースでの制限になる。
攻撃の際には、80/443を使う。
- 攻撃通信を制限できないやん！
実際問題としての対応
- プロキシ(Squid)を実装して、trendmicro.comを通す。
- DSaaS側では、FireレピュテーションとWebレピュテーション、DSaaS管理側でプロキシの使用を設定する。
- パブリッククラウドでOutBoundを絞るのは意外と少ないんじゃないかな。
まとめ
- クラウドではOutboundのURLフィルタリングができないので、プロキシでの実装が必要
- 個人情報を持っていたりして気にする人は、Outboundを絞るのがいいんじゃないかな。
LT枠3 ハンズラボでのDS事情についてゆるっと
加藤さん (ハンズラボ株式会社)
加藤さんはAWSチーム（東急ハンズの９割がAWSを利用）
2015/2016でAWSsamuraiを輩出
オンプレとクラウドとのセキュリティの違い
- オンプレはネットワークを簡単に引けないので、自然と外部からの経路が増えない
- クラウドでは、ネットワークを簡単に弄れるので、監視しない経路での通信が発生しうる
クラウドの利点ととのトレードオフ
- 利点はスピード
- 個エンジニアの周知徹底
ホスト側で何があってもいい方針(インフラ側)
- publicにはなるべく置かない。Privateに隠蔽する。
- やむなくpublicに置く場合は、NAT GatewayにIGWを向ける。（ひょっとしたらアンチパターンかもしれないけど...）
使いにくいところ
- DBでMySQLやPostgresqlでも使えるようにしたい(無料のDBがいい)
- クラウドアカウント連携は便利だが、Private通信をしたいのに、Public通信になってしまった（いい方法があったら教えて！）
使えるところ
- AWSとの親和性が高い
- PCIDSS要件に多く対応している
- SAQの要件に対して、多く対応している
- 監査員との会話が楽になるかも
最後に
ユーザー企業の生の声が聞こえて楽しかったです。
次回をお楽しみに！
今日はここまでです。
お疲れ様でした。