Edited at

Deep Security User Night #4 レポート

More than 1 year has passed since last update.

こんにちは、ひろかずです。

4回目となる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日以上かかることが3割

事故を防ぐことが重要

だが、事故が起きた時の対応はもっと重要

Auto Healingシステム


  • 攻撃の未意味化

  • DeepSecurityで検知した変更をトリガーに、gitから短時間で復帰させる。

  • メンテナンス作業の効率化という副次的効果も(ロックファイル運用で、運用負荷を軽減)


LT枠1 CloudFormation Template for Amazon ECS with Deep Security Agent(俺達のCloud Formation)

姜さん (トレンドマイクロ株式会社)

サブタイトル:女神は微笑むのか


今日やること

CloudFormationをつかってスタック2つ


  • 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チーム(東急ハンズの9割がAWSを利用)

2015/2016でAWSsamuraiを輩出


オンプレとクラウドとのセキュリティの違い


  • オンプレはネットワークを簡単に引けないので、自然と外部からの経路が増えない

  • クラウドでは、ネットワークを簡単に弄れるので、監視しない経路での通信が発生しうる

クラウドの利点ととのトレードオフ


  • 利点はスピード

  • 個エンジニアの周知徹底

ホスト側で何があってもいい方針(インフラ側)


  • publicにはなるべく置かない。Privateに隠蔽する。

  • やむなくpublicに置く場合は、NAT GatewayにIGWを向ける。(ひょっとしたらアンチパターンかもしれないけど...)

使いにくいところ


  • DBでMySQLやPostgresqlでも使えるようにしたい(無料のDBがいい)

  • クラウドアカウント連携は便利だが、Private通信をしたいのに、Public通信になってしまった(いい方法があったら教えて!)

使えるところ


  • AWSとの親和性が高い

  • PCIDSS要件に多く対応している

  • SAQの要件に対して、多く対応している

  • 監査員との会話が楽になるかも


最後に

ユーザー企業の生の声が聞こえて楽しかったです。

次回をお楽しみに!

今日はここまでです。

お疲れ様でした。