システムの脆弱性、把握してますか? 〜 これからはじめる脆弱性管理

セキュリティ的な脅威となるバグや設定の不備は脆弱性と呼ばれ、現代のシステムにおいては非常に大きなリスクとして捉えられています。このような脆弱性は日々新しいものが発見され、一度チェックすれば安全性が担保されるというものではありません。そのためにも、システムにおける最新の脆弱性を把握し続け、適切に対応していく必要があります。
今回のとことんDevOps勉強会では継続的に脆弱性をスキャンし、脆弱性によるセキュリティのリスクを排除する脆弱性管理について、脆弱性管理ツールであるyamoryを題材に紹介します。

Transcript

1. システムの脆弱性、把握してますか?
   これからはじめる脆弱性管理
   日本仮想化技術株式会社
   水野 源 mizuno@VirtualTech.jp
   2023/08/02
   1
   

   View Slide

2. 日本仮想化技術株式会社 概要
   • 社名：日本仮想化技術株式会社
   • 設立：2006年12月
   • 資本金：3,000万円
   • 売上高：212,358千円（2019年7月期）
   • 本社：東京都渋谷区渋谷1-8-1
   • 取締役：宮原 徹（代表取締役社長兼CEO）・伊藤 宏通（取締役CTO）
   • スタッフ：8名（うち、6名が仮想化技術専門エンジニアです）
   • 仮想化技術に関する研究および開発
   • 仮想化技術に関する各種調査・導入運用サポート
   • 自動化・DevOps支援
   • 5G・MECに関わる研究開発
   2
   ベンダーニュートラルな
   独立系仮想化技術の
   エキスパート集団
   

   View Slide

3. 発表者について
   • 水野 源
   • VTJ 技術部所属
   • Ubuntu JPメンバー
   • ubuntu.comメンバー
   • 日経Linuxにて「Linux 100%活用
   ガイド」を連載中(連載9年目)
   • ←こんな本を書きました
   3
   

   View Slide

4. 本日のアジェンダ
   • 脆弱性対策とは
   • 脆弱性情報の入手
   • ディストリビューションの脆弱性とは
   • パッケージバージョンの見かた
   • 脆弱性管理クラウドサービスの活用
   • yamoryとは
   • 脆弱性スキャンの種類
   • 脆弱性への対応
   4
   

   View Slide

5. 脆弱性対策してますか？
   5
   

   View Slide

6. 脆弱性対策してますか?
   • どんなプログラムにもバグは存在する
   • セキュリティ的な脅威となるバグや設定不備などの総称
   • → 脆弱性
   • 現代的なシステム、サービスではとにかくセキュリティが第一
   • 脆弱性は日々、新しく発見されている
   • これを放置すると、不正アクセス、情報流出、ランサムウェア感染など、様々
   な被害に合う可能性もある
   • 基本的に脆弱性は放置してはいけない
   6
   

   View Slide

7. 脆弱性情報を入手するには
   • まず、世の中に出回っている脆弱性を知る所からはじめよう
   • 脆弱性は一意に特定するために、番号をつけて管理するのが基本
   • 有名なところではCVEとか
   • https://cve.mitre.org/
   • Twitter XのCVEnewとか見ておくといいかも？
   • https://twitter.com/CVEnew
   7
   

   View Slide

8. ディストリの脆弱性情報を調べよう
   • 直接CVEを見ても「へー、このアプリに脆弱性見つかったんだー」で終わり
   • すべての脆弱性を追いかける必要はない
   • 「自分に影響するのはどれなのか」を知るのが大事
   • まず見るべきは、自分が使っているOSのパッケージの情報
   • UbuntuではUSNでパッケージごとのセキュリティ通知が見られる
   • https://ubuntu.com/security/notices
   • USNのRSSフィードをSlackに登録したり、ubuntu-security-announceメーリングリス
   トを購読するのも有効
   • CVE番号から、その脆弱性が影響するUbuntuのパッケージや、修正状態
   を調べることができる
   • https://ubuntu.com/security/cves
   8
   

   View Slide

9. Ubuntu Security Notices
   9
   

   View Slide

10. Ubuntu CVE reports
    10
    

    View Slide

11. Upstreamバージョンとパッケージバージョン
    • ディストリの脆弱性情報を知るにあたって重要なのが、パッケージの
    バージョンとセキュリティアップデートの方針
    • Ubuntuのようなディストリでは、リリース後にアプリのバージョンを上
    げることは基本的にしない
    • あるアプリのバージョン1.0.Xのパッケージが含まれてリリースされた場合、5
    年後でもこのアプリのバージョンは1.0.Xのまま
    11
    

    View Slide

12. 具体例: opensslパッケージ(1)
    • Ubuntu 22.04 LTSのOpenSSLのバージョンは3.0.2
    • バッファオーバーリードによるサービス停止の可能性がある脆弱性
    CVE-2023-1255は、upstreamではOpenSSL 3.1.1で修正された
    • 通常であれば、このバージョンにOpenSSLをアップデートする必要がある
    • しかしコアなライブラリのバージョンを上げると、システムへのインパクトが非
    常に大きい
    • そこで一般的なディストリでは、アプリやライブラリそのもののバージョンは
    上げず、セキュリティ修正のみを新バージョンから「バックポート」する
    12
    

    View Slide

13. 具体例: opensslパッケージ(2)
    • Ubuntu 22.04リリース時(2022年4月)のパッケージバージョン
    • openssl_3.0.2-0ubuntu1
    • 現在(2023年7月)のパッケージバージョン
    • openssl_3.0.2-0ubuntu1.10
    • OpenSSL自体のバージョンは3.0.2のままだが、「パッケージバージョ
    ン」が上がっているのがわかる
    13
    

    View Slide

14. 具体例: opensslパッケージ(3)
    • CVE-2023-1255の修正は、3.0.2-0ubuntu1.10でバックポートされた
    14
    

    View Slide

15. 具体例: opensslパッケージ(4)
    • つまりUbuntu 22.04では、OpenSSLのバージョン自体は3.0.2のまま
    だが、3.1.1の修正も含まれているので安心
    • 5年間のセキュリティサポートとはこういうこと
    • パッケージにセキュリティ修正が当たっているかは、単純にupstream
    のバージョン文字列を見ただけでは判断できない
    • 「OpenSSL 3.0.2!? 古すぎ!!」ではない
    • ディストリ固有のパッチを見て判断する必要がある
    • 一般的なLinuxディストリビューションでは、セキュリティパッチはバックポート
    して適用されているため、upstreamのバージョン文字列で判定しようとしては
    いけないのが大原則
    15
    

    View Slide

16. こういう事情を知らない(えらい)人がいると
    16
    こんな脆弱性が話題になってるので、全サーバーのOpenSSLライブラリの
    バージョンを調査して至急報告してください
    openssl_3.0.2-0ubuntu1.10です
    3.0.2は問題があるので、3.1.1以上にバージョンアップしてください
    いえ、パッケージにセキュリティパッチが当たっているので解決済みです
    全社的にバージョンアップの指示が来ているので、とにかく3.1.1以上のバー
    ジョンに上げないとダメです
    

    View Slide

17. つらい
    17
    ポンコツなセキュリティスキャナを導入しちゃうと、単純にバージョン文字列を比較して、こういうことを言ってきたりしてつらい。
    検索ワード: gihyo.jp 盲腸
    

    View Slide

18. 脆弱性があるのはサーバーOSだけじゃない
    • DockerHubからPullして使ってるコンテナの中身は？
    • アプリがrequireしている外部ライブラリは？
    • ルーターやファイアウォールのファームウェアは最新？
    • クラウドサービスの設定は適切？
    • これを全部チェックして、適切にな状態に管理できる？
    • 人力ではきつい
    • → セキュリティスキャナや脆弱性管理サービスを活用しよう
    18
    

    View Slide

19. 脆弱性管理クラウドサービス「yamory」
    19
    

    View Slide

20. 脆弱性管理クラウドサービス「yamory」とは
    • オールインワンの脆弱性管理クラウドサービス
    • https://yamory.io/
    20
    

    View Slide

21. yamoryの特徴
    • サーバーやコンテナ、アプリ、IT資産を登録すると、脆弱性データ
    ベースと突き合わせ、脆弱性をチェック
    • 一度情報を登録すれば、毎日定期的に脆弱性診断を行ってくれる
    • ルーターのファームウェアなども管理可能
    • 見つかった脆弱性は、独自のスコアリングルールに基いて、自動的
    に脅威度を設定
    • 脆弱性の状況をメールやチャットで通知可能
    • 脆弱性の修正状態の管理が可能
    21
    

    View Slide

22. ホストスキャン
    • LinuxサーバーやWindowsサーバーの脆弱性をスキャンできる機能
    • yamori-cliクライアントをインストールして、Cronなどで定期的に実行
    • yamori-cliはインストールされているパッケージ情報などを、「アセット」として
    クラウドのサーバーに、マシンごとに登録する
    • 毎日、登録されたアセットと脆弱性データベースの照合が行われ、脆弱性が
    存在した場合は通知される
    • スキャンはSSH越しに行うことも可能
    • 複数のサーバーが存在する場合、すべてにyamory-cliをインストールして
    Cronの設定をするのは大変
    • SSHスキャンであれば、踏み台サーバーにyamory-cliをインストールして、ス
    キャン対象の設定を行うだけでよい
    22
    

    View Slide

23. ホストスキャン
    23
    

    View Slide

24. コンテナスキャン
    • DockerHubなどコンテナレジストリに存在するコンテナイメージをス
    キャンする機能
    • コンテナのイメージタグを指定することで、ホストスキャン同様に日時
    でスキャンが行われる
    • バックエンドにはTrivyが使用されている
    24
    

    View Slide

25. コンテナスキャン
    25
    

    View Slide

26. アプリライブラリスキャン
    • アプリケーションのGitリポジトリを登録し、使用しているライブラリの
    脆弱性をスキャンする
    • Node.jsならnpmだったり、PHPならcomposerだったり、言語ごとのパッケージ
    管理システムを使ってライブラリをインストールするのが一般的
    • yamoryはアプリのGitリポジトリを登録すると、こうしたパッケージ管理システ
    ムを検出し、インストールされるライブラリをチェックしてくれる
    • GitHubのDependabotのような機能
    • GitHubとの連携が可能
    • ダウンロードしたソースコードをスキャンすることも可能
    26
    

    View Slide

27. クラウド設定管理(CSPM)
    • 現代的なインフラ構築には、AWSなどのIaaSを使うのが一般的
    • クラウドのセキュリティ対策はとても大事だが……
    • IAMユーザーに弱いパスワードが設定されていたり
    • 無駄に強い権限を持ったロールが払い出されていたり
    • セキュリティグループにPublicからのSSHを許可するルールが追加されていたり
    • など、「クラウドの設定の不備」というものがよくある
    • そしてこれらを人力でチェックして回るのは大変
    • CSPMは、クラウドのアカウントを連携させることで、こうした不適切な設定
    を洗い出し、リストアップすることができる
    • 新しいプロジェクトを開始したら、まずはまっさらなクラウドアカウントと
    yamoryを連携させてみて、初期構築前に問題点の洗い出しをしてみると
    いいかもしれない
    27
    

    View Slide

28. クラウド設定管理(CSPM)
    28
    

    View Slide

29. IT資産管理
    • ルーターやファイアウォールのファームウェアを最新に保つのも大事
    • だがサーバーOSと違い、ツールをインストールしての監視などが苦手
    • yamory-cliがインストールできないIT資産を、半手動で管理する仕組
    みがIT資産管理
    • 対象のIT資産と資産を特定するための情報、ファームウェアのバージョンな
    どを登録することで、脆弱性のチェックが行える
    • 言ってみれば、今までエクセルで行っていた資産管理を、もうちょっとリッチ
    にやってくれる機能みたいなもの
    • 例えば弊社では、CiscoやYAMAHAのルーターや、Fortigateのファイ
    アウォールなどを管理している
    29
    

    View Slide

30. 脆弱性への対応
    30
    

    View Slide

31. 脆弱性への対応の原則
    • 基本的に脆弱性は放置してはいけない
    • とはいえ、すべての脆弱性に対応する必要もない
    • 脆弱性のスコアが高い=緊急対応が必要という意味でもない
    • どんなに重大な脆弱性であっても、自分のシステムに対して、現実
    的に攻撃が不可能なのであれば緊急度は低い
    • そのため脆弱性スコアを鵜呑みにしてはいけない
    • 大切なのは、その脆弱性がどのくらい影響するかを把握し、正しく優
    先順位をつけて対応すること(トリアージ)
    • 正しいトリアージができないと、見つかった脆弱性は全部なくせとか言い出
    す人がでてくる
    • そんなことをしても、意味もなく現場が疲弊するだけ
    31
    

    View Slide

32. スコアリングと状態管理
    • yamoryでは同じ脆弱性でも、対象のホストの公開状態によって脅威度を変化さ
    せるなど、柔軟なスコアリングシステムを採用している
    • 「Immediate」「Delayed」「Minor」「None」の4段階
    • 見つかった脆弱性ごとに、対応状況を管理できる
    • 重大な脆弱性でも、インターネットに公開していないため影響を受けないホストもある
    • だが影響しないからといって何もしないと、脆弱性を放置しているように見えてしまう
    • そのような場合は、ステータスを「修正しない」や「誤検知」とするなどが可能
    • 週ごとの脆弱性の対応状況の推移もグラフで確認できる
    • サボってたりするとすぐわかる
    • 新たに見つかった脆弱性や、週次のレポートは、メールなどで通知もできる
    32
    

    View Slide

33. まとめ
    33
    

    View Slide

34. まとめ
    • どんなシステムにも脆弱性はある
    • → ディストリの仕様も含めてちゃんと把握しましょう
    • 脆弱性は放置しちゃだめ
    • かといって、全スキャン全修正は現実的ではないし、無意味
    • → 対応すべき脆弱性を正しくトリアージしよう
    • ハンドリングできる支援ツールを使ってみるとよいのでは
    • → yamoryはなかなかよさげなので、興味があったら相談に乗りますよ
    34
    

    View Slide

35. DevOpsサポートサービス https://virtualtech.jp/devops/
    DevOpsを始めたいチームのための支援サービス
    開発プロジェクト
    • 開発環境
    • GitHubリポジトリ
    • CI/CD
    • IaC (デプロイ環境)
    運用チーム
    • 運用監視
    • 脆弱性スキャン
    • インシデント管理
    • IaC (共通インフラ)
    運用をまるっとお任せしたい
    おまかせDevOps
    (かんたんDevOpsに加えて)
    DevOps環境の運用・改善
    インフラコードの保守
    発生したインシデントへの対応
    DevOps人材を育成したい
    かんたんDevOps
    DevOpsの環境初期構築
    インフラのコード化
    DevOpsプロセスの実践手順書・支援
    技術サポート
    

    View Slide