[レポート]Sansan の成長を支えるセキュリティログの活用と Amazon Elasticsearch Service – AWS Security Roadshow Japan 2020 #awscloud #AWSSecurityRoadshow

AWS Security Roadshow Japan 2020で行われた「Sansan の成長を支えるセキュリティログの活用と Amazon Elasticsearch Service」のレポートです

#AWS Security Roadshow Japan 2020

#Amazon Elasticsearch Service

#セキュリティ

#AWS

臼田佳祐

2020.10.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

本日はAWS Security Roadshow Japan 2020で行われた以下の講演のレポートです。

お客様事例 2

「Sansan の成長を支えるセキュリティログの活用と Amazon Elasticsearch Service」

松田健氏

（Sansan 株式会社 CSIRT）

レポート

Sansan-CSIRT が抱えていた課題と解決策、ログ管理検索基盤のメリット、将来の方向性について話す
松田健氏
- 普段の業務
  - SOCチームで運用と改善
  - 脅威情報の収集と改善
名刺管理がどうイノベーションを生み出すのか
- 誰と誰がいつであったかのアクティビティデータ
- プロフィールデータ
- 未だに紙が利用されている
- 業務効率化やイノベーションにつながる
SanSanとEightを提供している
- SanSanは6,000社を超えている
- オンライン名刺交換もリリースした
- Eightは270万人利用
- BillOneという請求書のデータ管理サービも出している
サービスの拡大とともに、守るもの、ユーザーが増えていく
これらを守るためにCIO直轄でCSIRTがいる
- 各事業部にCSIRT兼務してもらっている
- 隅々までセキュリティを行き届かせるため
SanSan-CSIRT
- 3つの組織から構成されている
- 守る対象は組織全体
- 全社的なセキュリティ対策をリードしている
「セキュリティと利便性を両立させる」という会社の理念がある

ログ分析基盤

SIEMというとわかりやすいかも
- 例えばある端末でマルウェア感染した場合、感染後の通信を特定する必要がある
- AD/DNSなどのログを1つ1つ見ていく必要がある
- SIEMではこれらをつなぎ合わせて素早く確認できる
- インシデントを早期に発見できる
- インシデントが発生してからログをかき集める必要がなくなる
ログ分析基盤に求めていること
- ログを長期間保存し、いつでも検索できること
- 分析者のバイアスを取り除くこと
  - いつ何が起こったか正確に把握する必要がある
  - 熟練者でもミスやバイアスがある
    - なれている、情報量が多いなど
- 当たり前のことだが重要
「当たり前のことを当たり前に」
- これを実現するためのログ分析基盤
SOCチームでは様々なログを扱う
- AWSサービス
- AWSセキュリティ
- 社内システム
- セキュリティ対策製品
「時代はゼロトラスト」
ゼロトラストに向き合う
- どこでも安全に生産性を落とさずに働ける環境を目指す
- 対策をエンドポイントに寄せていく
ゼロトラスト x ログ分析基盤
- 適合していく必要がある
ゼロトラストの弊害
- 可視性が高いログの情報量が多い
  - ログの量が桁違いに増加する
- 可視性の持続性がない
  - セキュリティ対策製品のログも数週間で消える
見えてきた課題
- ログ量の急激な増加に耐えられない
- 運用コストが増加している
いざというときに頼れる存在でなければならない
- セキュリティ対策には限界がある
- シンプルな作りでスケールしやすい基盤に進化される方法を考えた
Amazon Elasticsearch Serviceを用いたログ分析基盤を構築することに至った

Amazon Elasticsearch Serviceによるログ分析基盤

Amazon Elasticsearch Service(AES)とは
- オープンソースのElasticsearchとKibanaを簡単にデプロイ・管理するフルマネージドサービス
  - 高い可用性とパフォーマンス
- Open Distro for Elasticsearchを活用する
  - エンタープライズ相当のセキュリティ機能やアラートを活用できる
アーキテクチャ

5つの特徴がある
- S3を中心とした構成
  - 全てのログをS3に配置
  - 非常に高い可用性
- es-loaderで読み込んでESへロード
- 一定時間経過後コスト効率がいいUltraWarmに移動する
  - 変更はできないが検索はできる
- UltraWarmからも削除してGlacierへアーカイブ
- Open Distroでマルチテナンシー
  - CSIRT以外にも閲覧可能に
  - Cognitoと連携して認証認可を強化
es-loaderについて
- AWS中島さんが開発してGitHubで公開されている
- SanSanも初期から参加して測定している
特徴
- ログをシンプルにAESへロードする
- 様々なサービスと形式の加工に対応している
  - AWS以外のサービスもできる
  - syslogやCSVなどファイルフォーマットもいろいろ対応
  - 独自のフォーマットでも数行追加するだけで取り込める
  - SanSanでもいろんなものを取り込んでいる
ログの検索と正規化
- es-loaderの重要な機能
- 検索するときに重要
- ログソース毎に異なるフィールドがある
  - 送信元もsource_ipやsipなどいろいろある
  - これによりクエリが長くなる
  - 一刻を争うインシデント発生時に非効率となる
- 正規化
  - Elastic Common Schemaへマッピング
  - 後から直すのではなくログソース毎定義する
  - es-loaderで簡単に正規化する
ここまでのまとめ
1. ログはS3に保管し、⽋損しない状態とする
2. es-loaderでシンプルに検索できる状態とする
3. UltraWarmで検索できる期間のコストを抑える
4. コストを抑えて⻑期間のログ保管を実現する
5. ログを全社的に活⽤できる状態とする
構築してみた結果
- ログ量の増加にも対応できる
  - マネージドサービス・サーバーレスなのでメンテナンスは最小限
  - 属人化を防ぐことができる
- 一般的なログ管理製品と比べてコストを1/3以下にできる
- 残念な点
  - UltraWarmノードがリザーブとインスタンスに対応していない
  - これができれば更にコストカットできる
CloudFormationによる導入をサポートしている
- 手軽に導入可能
- まず使ってみるができる

今後の取組について

長期間の検索、その先へ
- 各事業のログも管理し、横断的に検索できる状態とする
- 組織の弱点を特定する
  - ペネトレーションテスト
  - パープルチーミング
  - 場当たり的な対策ではなく原因を明確化するためにログ分析基盤を活用する
当たり前のことをAWSで
- 当たり前は複雑であってはいけない
- シンプルにするためにAWSをうまく活用する
セキュリティで事業を支えるということを忘れない
- セキュリティがビジネスの妨げになってはならない
- 定期的に見直す
- できるだけ自動化したり、省力化したり
構想から運用開始まで2ヶ月ちょっとだった
- AWSを利用することで最小のコストで実現できた