これは Akatsuki Advent Calendar 2019 20日目のネタです。
CTO兼セキュリティの責任者を担当している田中です。株式会社アカツキでは、ネットワークとエンドポイントデバイス、一部のビルドサーバ以外のリソースを全てクラウドに置いています。
「出来る限りクラウドを利用する」という考え方は事業の柔軟性を重視し、インフラ管理コストを下げたい企業では一般的になっているかと思います。
クラウドをインフラにすることであまりセキュリティを重視していない会社も多いと思います（昔のアカツキもそうでした）が、「個人情報を扱うようになった」「事業が成功した」といった事業状況の変化によって求められるセキュリティレベルも変わってきます。
セキュリティを意識せずに開発していた時代から現在まで、様々なセキュリティ対策を検討し、実施してきました。 セキュリティは組織・プロセス・規範/法律・技術と様々な観点がありますが、この記事では技術面の対策に焦点を当てて、どのような対策をしてきたか、その一部を紹介したいと思います。
ID管理とSSO
大雑把に言えば、セキュリティを管理するということは、何を信用するかを管理することです。 クラウドを利用しているということは、誰かが認証/認可を管理しているはずですが、中央集権的なID基盤が無いと退職/異動の権限設定の漏れが発生したり、インシデント発生時に迅速な対応ができない等の問題が発生します。
ID管理には Single source of truth (SSOT) という考え方がとても重要です。 アカツキではADをID管理のSSOTとしています。システム構成は以下のイメージです。
| システム | 役割 |
|---|---|
| AD | ID管理のSSOT |
| Azure AD | Office365ライセンスの認証 |
| OneLogin | SSO( Single Sign On )の管理 |
Active Directory (AD)
ID管理の中心となるデータソースです。個人を一意に識別するための情報を管理しています。 以下の情報をOUとしてメンテナンスしており、プロビジョニングの属性として利用可能にしています。
- 所属会社
- 雇用形態
- 所属組織
- 職位
詳しい方は「全部クラウドならJumpCloudのようなCloud Directoryを使うほうが良いのでは？」「OktaやOneLoginのようなIdentity Provider (IdP)があればADは不要では？」と思うかもしれません。 当時は、以下の理由から、この構成になりました。
- プリンターの認証など、ADDS認証しか対応していない機器があるため、ADが必要
- Microsoft ライセンスの管理にAzureADが必要
- AzureADは管理機能が不足しており、IdPとしてはOneLoginのような便利なものを使いたい
ADは古くからあるので、周辺ツールも充実しています。検討した結果、ADManager Plusというツールが使いやすかったので、これをADの運用に利用しています。
AzureAD
Azure AD Connect を利用して、ADで管理しているIDをAzure ADへ同期しています。 Microsoft Office365 ライセンスの認証にAzure ADが必須なので、Officeライセンスの認証のために、Azure ADと同期しています。
2016年にはシングルフォレストドメインしか対応していなかったAzure ADも、最近はID基盤として十分な機能と管理機能を持っています。 ADDS連携をAzure ADDS連携に置き換え、Azure ADをID管理のSSOTとする運用でも、問題ないような気がしています。
OneLogin
AWS、Googleアカウント、Slackやラクスルのようなサービスまで、様々なクラウドサービスへのSSOに利用しています。 また、ネットワーク機器の管理画面やツール等の自社アプリケーション、Jenkinsへのログイン等、社内メンバーのIDを元に認証したい全てのツールを、OneLoginで認証するように設定しています。
OneLoginは機能表で比較すると、Oktaのように高くないし、機能が多くて魅力的です。採用当時は機能の多さと、担当者の経験により、OneLoginを選定しました。
運用をしていくうちに管理画面が微妙に使いづらい（保存時の余計なダイアログにより保存できなかったという事例が多発している、ロールのフィルターができないため操作対象を間違える等）、WebAPIのAPIトークンがほぼ全て強い権限を求める等の、細かい辛さも感じています。
今だったらどんな構成にするか？
Gartner Magic QuadrantやThe Forrester Waveを見ると、IdPとしてはOktaが最高評価を受けています。 ざっくりとOneLogin, Ping Identity, Oktaを比較検証しましたが、管理機能の使いやすさやカスタムアプリのフィールドカスタマイズ、対応アプリケーションの多さなど、Oktaが一つ頭を抜けている感覚もあります。
※ The Forrester WaveでLeaderに選出されているIdaptiveは試しておらず、少し気になっています。
ただ、Microsoft 365 E3 ライセンスを一つ持っているとPREMIUM P1, Microsoft 365 E5 ライセンスを一つ持っているとPREMIUM P2ライセンスが有効になるAzure ADはコスパという面では最高です。
今からID管理基盤を構築するならどうする？と問われたら、以下のどちらかの構成を検討します。
- 管理面でのストレスを最小限にしたい場合はOktaをID管理基盤としてAzure ADと連携する
- コストを最小限にしたい場合はAzure ADだけをID管理基盤として頑張る
CASB: Netskope
クラウドを業務の中核として利用していると、日々利用されるクラウドサービスが変わってきています。 アクセス制御してコントロールすることはやめたほうが良いでしょう。業務改善のスピードが遅くなりますし、自由さの阻害はShadow ITが生まれる原因にもなります。
とはいえ、危険なクラウドの利用を把握しない・追跡可能性が無い、というのはセキュリティ管理者の怠慢です。 アカツキではNetskopeを利用して、リスクが高いクラウドの利用を監視したり、DLP監視としてConfidentialな資料を社外からダウンロードされたときの監視をしています。
エンドポイントセキュリティ
EPP/EDR: CrowdStrike Falcon
この分野には様々な製品がありますが、アカツキではCrowdStrike Falconを利用しています。
EDRの機能を含むこと、Linux, Mac, Windows 問わず監視ができること、検知率が高いこと、ネットワーク遮断等の対応ができること、インシデント発生時に「どこで、どんなプロセスが動いていたか」を遡って検索できること、等が選定の理由です。
端末管理: Jamf / Intune
端末を配布した後に、エンドポイントセキュリティ製品が無効化されていたり、セキュリティ設定が変更されることを想定しておく必要があります。 MacはJamf、WindowsはIntuneを利用して、FalconやNetskopeが有効化されていることを確認しています。
監視
SIEM : SumoLogic
ADやネットワーク機器のログ、EDRのアラートや各種SaaSのログを、全て集約しています。 一箇所にログが集約されていることで、「OneLoginログイン時のリスクスコアが高いユーザが不審な行動をしていないか？」の検索や「全てのオフィスからのEmotetへの通信をアラートする」といった設定が、数分で可能になります。
セキュリティインシデント発生時は初動の調査速度がとても重要なので、SoC/CSIRTの運用をする上で、SIEMへのログ連携は必須だと考えています。
ネットワーク
ファイアーウォール
オフィスネットワークのファイアーウォールにはFortiGateを利用しています。 アンチウィルス機能、IPSによる侵入防御、Webコンテンツフィルタリングによるセキュリティ上問題のあるサイトのブロックを有効化しています。
また、ファイアーウォールの設定変更があった際にはSumoLogicからSlackにアラートを飛ばすように設定しており、意図せぬセキュリティホールが発生しないように監視しています。
ネットワーク監視: Verizon NDR
支給端末に十分なセキュリティ対策を施しているからといって、ネットワーク監視をしなくて良いという理由にはなりません。 LANケーブルにより不用意に接続されたデバイスの存在や、ネットワーク機器の脆弱性への攻撃を考慮する必要もあります。
アカツキでは、ネットワークレイヤの監視として、Verizon NDRを利用しています。 オフィスネットワークだけでなく、AWS/GCPのIaaS環境も監視対象とすることで、運用環境を攻撃された際に検知できるようにしています。
トリアージまでは パロンゴ社 にお願いしています。 アラート情報を流しているSlack channelをパロンゴ社との共有チャンネルとしています。 高い技術力を持ったパロンゴ社のメンバーにより、24時間365日 迅速な対応をしていただいており、とても助かっています。
秘匿情報を扱うクラウドサービス
全ての業務をクラウドで管理しているため、利用されているクラウドアプリケーションは200程度あります。 重要な情報を扱うサービス、攻撃を受けたときの影響が大きいサービスを把握し、常にセキュリティ対策を改善していくことが重要だと考えています。
利用している会社が多いであろうサービスをピックアップして、アカツキでの対策の工夫を紹介します。
AWS
AWSのセキュリティは考えることがたくさんありますが、クラスメソッドさんの AWSでのセキュリティ対策全部盛り 初級から中級まで という資料がまとまっていて最高です。
アカツキでは上記リンクにあるような基本的な対策に加えて、
- AWSアカウントを払い出したタイミングで十分なセキュリティ対策（AWS Config, CloudTrail, SIEMへの連携など）が施されている状態にする
- 運用が行き届かない古いAWSアカウントは狙われがちなので、不要になったらなるべく早くアカウントごと削除する
としておき、脆弱性を発生させるような操作が行われた場合に、すぐに気付けるようにしています。
もし、AWSのセキュリティ脆弱性に触れてみたい人は、以下の"crackme"サイトに挑戦してみて下さい。脆弱な環境はいかに簡単に生まれるかというのを、実感出来ると思います。
メール: Gmail
Emailはコミュニケーションの入り口ですので、攻撃者はよくEmailを送って侵入を図ります。
Gmailにはセキュリティサンドボックスにより不正なソフトウェアを発見する機能がありますので、有効化しています。
ストレージ: Google Drive
一般公開ファイルとしてリンク共有することはできない設定にしています。 しかし、「ドメイン内へのリンク共有」は気軽にできてしまうのがGoogle Driveの怖いところです。 特定の文字列をタイトル名に含むファイルや、特定の共有ドライブに対して、共有設定の監視をしています。
SIEMで監視しても良いのですが、監査ログのペイロードが大きすぎてパースできない場合もあるので、G Suiteの監査ログ画面から、アラートを作成しています。
アラートはメールの転送ルールでSlackに通知するよう、設定しています。
GitHub
GitHubは強力な開発支援ツールですが、大きなセキュリティホールでもあります。 AWS, GCP, GitHub, Slack 等のAPIトークンをGitHub Publicリポジトリに投稿してしまうと、すぐに他人に知られてしまいます。 例えば、https://shhgit.darkport.co.uk/ というサイトでは、GitHub に公開されたトークンをリアルタイムに発見することができます。
PublicリポジトリへのPushにだけ気をつければ良いかというとそうでもなく、GitHub Personal Access Tokenを不用意に公開してしまったり、PrivateリポジトリへのCollabolatorの登録間違いといったことでも、漏洩可能性があります。また、GitHubへのアクセストークンはCI/CD環境に保存されていることも多く、Jenkins環境をターゲットとして攻撃をするアクターも存在します。
アカツキでは、Privateリポジトリを捜査するツールを作成して、commitされているトークンを探し出しています。
Slack
Slackはインテグレーションが豊富なため、攻撃者に狙われやすいツールでもあります。 特にSlackのメッセージ内容を読み取ることが出来るAPIトークンは慎重になるべきです。 Slackアプリは承認を必須としており、以下のポリシーを元に承認可否を判断しています。
APIトークンやアプリの種類については、https://slack.com/intl/ja-jp/help/articles/215770388 を参考にして下さい。 aktsk や会社単位のワークスペースに対するアプリは、以下の様に判断します。その他ワークスペースは、ワークスペース管理者の判断におまかせしています。 ## 外部アプリケーション ### メッセージ内容を取得できる外部アプリ 以下スコープを要求する外部アプリケーションは原則拒否します。 メッセージが読めるスコープの一覧: bot channels:history conversations:history groups:history im:history mpim:history search:read stars:read メッセージ内容を取得する外部アプリは、信頼できる発行元かつ、連携しなければならない理由がある場合に限り承認しますので、申請理由を詳しくご記載下さい。 ### チャンネル名やDMのリストを取得することができる外部アプリ 以下スコープを要求するアプリケーションは、利用用途に応じて承認可否を検討します。申請理由を詳しくご記載下さい。 チャンネルを取得することができるスコープの一覧: channels:read groups:read mpim:read im:read ### Slack社によるレビューを通っていない外部アプリ Slack社によるレビューが実施されていないアプリケーションについては、原則承認しません。どうしても必要な場合は、申請理由をご記載下さい。 ## 内部（自作）アプリケーション 原則として、IP制限を必須とします。 その他は外部アプリケーションの判断基準に従います。 ## Slackアプリ以外のIntegration ### レガシーテストトークン どんな理由があっても、利用禁止です。ワークスペース設定で不許可としています。 ### Outgoing Webhook 取得元のチャンネル制限を必須とします。 ### Bot カスタムインテグレーションボットのユーザートークン は非推奨です。 自作のボットは、スコープを最小限にした内部アプリケーションへ置き換えて下さい。 ### Slash command, Incoming Webhook 特に制限しません。申請があったら承認します。
また、Slack Enterprise Gridの監査ログ、アクセスログをSIEMに連携しており、インシデント発生時に追跡できるようにしています。
トークンの管理
チェック
標的型攻撃におけるCyber Kill Chainを元に技術的対策を分類してみました。 クラウド中心にシステムを運用している会社にとって、以下のチェック項目がご参考になれば幸いです。
偵察
侵入に使えそうな情報を収集する行為です。企業サイト、SNS、公開サーバなどが調査対象になります。
[対策]
監視していない、運用されていない場所があると、侵入される危険性が高くなります。不要なサーバやクラウドサービスは削除しましょう。
- 中央集権的ID管理ができているか？退職や異動について、即日対応できているか？
- 開発用のサーバ等、不必要にポート公開していないか？
- 古いサーバ・運用されていないサーバはないか？
- CASBによって誰がどのようなクラウドサービスを利用しているか把握し、リスクを管理できているか？
武器化
エクスプロイトコードやマルウェアを作成し、メールやSNSを使って送付します。 URLをクリックすると、BeEF が実行され、内部ネットワークの脆弱性を把握するといった攻撃手法もあります。 最近は Emotetの被害が主にWordファイルによって拡大していたりします。
[対策]
メールはサイバー攻撃の入り口としてまだ多く利用されていますので、対策しましょう。攻撃手法に関する情報を得ておくことも重要です。
- JPCERTなど信頼できるコミュニティから、注意喚起情報を得ているか？
- メールのサンドボックス機能等により、マルウェアがダウンロードされる前に隔離する対策ができているか？
- C&CサーバやフィッシングサイトのWebフィルタリングは設定されているか？
デリバリー
メールの添付ファイルや、レジュメにカモフラージュしたURL等によって、マルウェアに感染させます。 ファイアーウォールやVPNに脆弱性があれば、そこから侵入されこの段階まで進まれます。
[対策]
エンドポイントセキュリティが重要です。
- エンドポイントデバイスにEDR製品（最低でもEPP製品）がインストールされているか？
- エンドポイントデバイスのEDR稼働状況を、Jamf/Intune等のデバイス管理ソフトウェアでチェックできているか？
- VPNは無効化されているか？VPNを利用している場合は、適切に運用され、監視できているか？
エクスプロイト/侵入
侵入に成功したPCから、内部ネットワークの構造を把握し、機密情報が保存されている場所を探し、アクセス権限を盗み取ります。
[対策]
内部ネットワークの攻撃を防止/検知するための対策や、脆弱性調査を行いましょう。
- IPS/IDSが運用されているか？
- ファイアーウォールは適切に設定されているか？
- ネットワークの監視（例: C&Cサーバやランサムウェアが置かれていたホストへのアクセス）ができているか？
- NDR等のネットワーク監視の製品により、エンドポイントデバイスからの不審な通信を監視できているか？
- 定期的な内部ネットワーク診断により、社内ネットワークからの脆弱性を発見できているか？
- 利用しているネットワーク機器やソフトウェアのバージョンを把握しており、迅速にセキュリティパッチを適用できているか？
潜伏/目的の実行
情報の盗み出し、システムの改ざん、ログの消去を行います。
[対策]
ここまでKill chainが進んでいたら予防は難しいので、素早く攻撃を発見できることが重要です。 また、ログの消去を難しくするように、SIEMに連携しておくことも重要です。
- 重要な情報を扱うツールのアクセスログは全てSIEMに連携されているか？
- SIEMのアクセスログ監視は、継続的にアップデートされているか？
- 各ツールの特権ユーザのアクティビティやS3の公開設定の変更など、特に重要な操作をアラートできているか？
- 開発環境や外部からアクセス可能な本番環境にも、EDR及びネットワーク監視が適用されているか？
- AWSやGCPの監査ログを監視できているか？（IAMユーザの作成や国外からのコンソールアクセスなど、不審なアクティビティを監視できているか？）
