[レポート] 急速に拡大するLINEの社内イントラネットのセキュリティ強化における開発者とセキュリティ・チームのアドベンチャー #linedevday_report

急速に拡大するLINEの社内イントラネットのセキュリティ強化における開発者とセキュリティ・チームのアドベンチャー

2019年11月20日（水）・21日（木）にグランドニッコー東京 台場でLINEのデベロッパーカンファレンス「LINE DEVELOPER DAY 2019」が開催されました。

• LINE DEVELOPER DAY 2019

本記事は、セッション「急速に拡大するLINEの社内イントラネットのセキュリティ強化における開発者とセキュリティ・チームのアドベンチャー」をレポートします。

スピーカー

ByoungYun Lee氏（LINE Plus GrayLab Security Engineer）

LINEのセキュリティエンジニア。2018年にLINEに入社する以前は、GrayHashでセキュリティ・コンサルティングと侵入テストを担当。その経験を生かして、LINEが提供するサービスのソフトウエアとインフラのセキュリティリスク評価の責任者を務めている。LINEのサービスのコードを見直すことがこのうえなく好き。

セッション概要

LINEのサービスが成長し、新たなサービスがリリースされるにつれ、われわれのイントラネットの規模は急激に拡大しています。セリュリティ上の脅威も、イントラネットの複雑化とともに増大しているため、各サービスのセキュリティ・レベルを上げることが不可欠です。本セッションでは、ネットワーク・レベルでのアクセス・コントロールを通じて主要サービスのセキュリティ・レベルを強化した方法についてご説明します。当社の複雑なイントラネット全体で提供されているサービスを、一時停止などすることなくより安全にした方法、その作業中に開発チームとセキュリティ・チームがどのように連携したかについてお話ししたいと思います。また新たなセキュリティ対策によって生じた不都合にどのように対処したのかについてもご説明します。

スライド

レポート

• セキュリティ事故が多数起きている
• Public Network
  • WebとAPIはパブリック
  • DBはプライベート
  • DBにパスワードをかけてアクセスする
  • パスワードを漏洩した場合
  • ポートスキャンで攻撃ポートを検出する
  • 権限の昇格やマルウェアをインストールなど
  • この仕組みは脆弱性があるのでどうするか？
• Private Network
  • DatabaseをPrivate Networkに
  • Web, APIのみPublic
  • これによりすこしSecureに
• Lateral Movement Attack
  • ただ規模が大きくなるとメンテナンスされてないサーバーから侵入し攻撃される
• LINE's Infrastructure
  • たくさんのサーバーがある
  • サービスごとにプライベートネットワークを分割している
  • いずれかが攻撃されても分割されているので侵害できない
  • データベースは、サービスごとにアクセスポートを変えている
  • 数百のDBに数千のAPIがありまたデータセンターが分散されているので複雑で難しくなります。
• Hardening
  • ネットワークレベルで不必要なアクセスを全て遮断する
  • 要件のリストアップ
    • マルチリージョン
    • 社内クラウドインフラのサポート
    • 既存サービスに導入できる
  • iptables
    • 簡単に使うことができコストがかからない
    • 物理的な製薬なしでクラウドインフラでも利用できる
    • 悪いこと
      • 誰でもセキュリティホールを作れてしまう
      • 保守性が低い（全て統合管理できない）
  • Network Firewalls
    • オーバヘッドなく
    • LINEはすでに利用しているので知見、経験がある
    • 悪いこと
      • 全てのネットワークに必要なのでコストが高い
      • クラウド内のネットワーク制御では使えない
  • Host-Based Firewall
    • ルールを作り、Firewallをインストールし、実行する
    • iptablesで不足していたものを補えるかもしれない
    • DeepSecurityがデプロイ済みなので統合管理できユーザー権限も制御できる
  • Step
    • ターゲットを分析
      • クリティカルなサービスのDBから分析
      • 700のホスト、27のグループ、2000のクライアント
      • 互換性のために古いバージョンもある
      • 分散されたAPIサーバーからDBへアクセスする
      • 各々のサービスにルールを作成する必要があり、ダウンタイム・停止はできない
    • デザインプロセス
      • 全てのDBのネットワークコネクションを認識をリスト化
      • Db関連ポートだけでなく他のポートも利用しているのでインフラマネジメントチームがリストを定義しルール化
      • Host Firewallをインストールをする必要があり、バッチでもいれることができるがマネジメントコンソールが必要である
      • ルールをアサインすると不必要な接続をブロックできる
      • サービスリリース中なのでダウンタイムや停止ができない
      • エージェントインストール時にエージェントソフトウェアでエラーが起きる可能性があるかもしれない
      • ルール適用後サービスパフォーマンスに影響があるかもしれない
      • Faulty RUles
        • 間違ったルールを入れないようにする
      • Unpredictable Failure
        • 冗長したサーバの内、1つテストサーバーにてテストをした
    • 適用
      • 1つのステップずつ実行しうまくいかなければ切り戻す
  • Realtime Communication
    • 開発、インフラチームとセキュリティチームで通知を徹底し何かあれば修正しつぎのステップへ実行する
  • Alert System
    • Human Error起因でAPIが停止してしまった。
    • 検知が難しいので復旧を早くするためにアラートを作成した。
    • アラートではどの経路でエラーがでたかを通知することでより理解しやすいようにした
  • Scale out
    • デプロイからLBのアサイン前に検知をして確認
  • Episode
    • 不明の通知がきたので調べてみると、スキャンされているかと思ったが社内ペネテストをしていただけだった。
  • Issue
    • うまく実行がされているが、緊急メンテナンスやデプロイがセキュリティチームのサポートが必要
    • 高度な設定のためメンテナンスが大変
    • ルール変更などが複雑でわかりずらい
    • 簡単なルールだけを提供してUIで変更できるよにし新しいデプロイを検知して自動化で拡張できるようにする
• Epilogue
  • 開発チーム、インフラチームの理解によりサービス停止なく実行できた。
  • LINEはもっとセキュリティを向上させるというポリシーでやっていく。

まとめ

LINE内部でのセキュリティの考え方がわかりました。基本的な部分ではありますが、LINEほどの規模で徹底できているチーム体制とインフラ・開発のチームとの連携が密になされているからこそ実現できてると思いますので改めてチームの横断連携の重要性を理解しました。