Upgrade to Pro — share decks privately, control downloads, hide ads and more …

脆弱性対応を支える技術/20221127_JJUG-CCC-2022-Fall

skaji18
November 27, 2022

 脆弱性対応を支える技術/20221127_JJUG-CCC-2022-Fall

skaji18

November 27, 2022
Tweet

More Decks by skaji18

Other Decks in Technology

Transcript

  1. ©2022 RAKUS Co., Ltd.
    脆弱性対応を支える技術
    JJUG CCC 2022 Fall - 2022.11.27
    梶紳之介

    View Slide

  2. 自己紹介
    ● 梶紳之介
    ● 株式会社ラクス
    ● 人事労務管理サービス の開発
    ● Java、Vue.js、(PHP)
    2
    @s_kaji_18

    View Slide

  3. 脆弱性対応、うまくいってますか?
    3

    View Slide

  4. 例えばこんな課題、ありませんか?
    4

    View Slide

  5. やらなきゃいけないけど...
    ● 自動テストがなく、手動テストが必要
    ○ 😇 品質担保に時間がかかる
    ○ 😇 テストにかける人員/リソースを用意できない
    ● リリースにサービス停止が必要
    ○ 😇 顧客影響が発生するため、ビジネスサイドから敬遠される
    5
    特に
    緊急リリース
    の場合

    View Slide

  6. 今日お話すること
    6
    私達の開発チームが実践している、脆弱性対応をより早く、より安全
    にリリースするためのポイントをご紹介します
    キーワード
    ● 自動テスト
    ● 無停止リリース

    View Slide

  7. 目次
    ● 前提
    ○ 技術スタック概要
    ● 脆弱性対応のポイント解説
    ○ バージョンアップ環境の準備
    ○ テストによる品質担保
    ○ リリース
    ○ メンバーのローカル環境更新
    ● まとめ
    7

    View Slide

  8. 8
    技術スタック概要
    ※今日お話する内容に関連する技術のみ抜粋
    ● アプリケーション構成
    ○ Java
    ○ Spring Boot
    ● 実行環境
    ○ コンテナ(Docker) on AWS

    View Slide

  9. 過去事例に沿ってポイント解説
    9
    ※事例として Javaのアップデート を扱います

    View Slide

  10. ● バージョンアップ環境の準備

    ● テストによる品質担保

    ● リリース

    ● メンバーのローカル環境更新

    ・Oracle Critical Patch Updates の公開
    ・脆弱性対応バージョン のリリース
    10

    View Slide

  11. 11
    ● バージョンアップ環境の準備

    ● テストによる品質担保

    ● リリース

    ● メンバーのローカル環境更新

    ・Oracle Critical Patch Updates の公開
    ・脆弱性対応バージョン のリリース

    View Slide

  12. 12
    バージョンアップ環境の準備
    Java を脆弱性対応バージョンにアップデートする
    ● 前提: コンテナ(Docker)を採用
    ● → Dockerfile を1行更新するだけ
    - FROM amazoncorretto:17.0.3-alpine3.15
    + FROM amazoncorretto:17.0.4-alpine3.15
    ARG JAR_FILE=target/*.jar
    COPY ${JAR_FILE} app.jar
    ENTRYPOINT ["java","-jar","/app.jar"]

    View Slide

  13. 補足: 依存ライブラリの更新
    ● 前提: Javaプログラムの依存関係は Gradle で管理
    ● build.gradle の依存関係を更新するだけ
    13

    plugins {
    - id 'org.springframework.boot' version '2.7.3'
    + id 'org.springframework.boot' version '2.7.4'
    }

    View Slide

  14. 14
    ● バージョンアップ環境の準備

    ● テストによる品質担保

    ● リリース

    ● メンバーのローカル環境更新

    ・Oracle Critical Patch Updates の公開
    ・脆弱性対応バージョン のリリース

    View Slide

  15. 自動テスト で品質担保
    テストによる品質担保
    15
    テスト観点・指標
    カバレッジ
    リグレッション
    テスト手法
    ユニットテスト
    E2Eテスト

    View Slide

  16. Java プログラムのメソッドレベルの入出力が期待どおりの動作をし
    ているかを確認する
    ● JUnit5 を採用
    ● カバレッジは 約85%
    ○ サービス開発当初から「テストは書くことが当たり前」の文化
    ○ 特にユニットテストは開発ガイドラインとして定めている
    ユニットテスト
    16

    View Slide

  17. 17
    ユニットテスト
    リグレッション観点では、以下の重要機能の動作を確認している
    ● 帳票PDF作成


    ● 外部API連携

    View Slide

  18. ユニットテスト
    リグレッション観点では、以下の重要機能の動作を確認している
    ● 帳票PDF作成
    ○ 作成したPDFのレイアウトが崩れていないか確認する
    ○ Apache PDFBox で画像変換して新旧比較
    ● 外部API連携
    ○ 想定しているフロー/データのままで連携できるか確認する
    ○ 連携先でバッチ処理される(15分前後)までポーリングする
    18

    View Slide

  19. ユニットテスト
    リグレッション観点では、以下の重要機能の動作を確認している
    ● 帳票PDF作成
    ○ 作成したPDFのレイアウトが崩れていないか確認する
    ○ Apache PDFBox で画像変換して新旧比較
    ● 外部API連携
    ○ 想定しているフロー/データのままで連携できるか確認する
    ○ 連携先でバッチ処理される(15分前後)までポーリングする
    19
    関連資料: 変わりゆくAPI連携仕様との付き合い方
    https://speakerdeck.com/nologyance/good-practice-of-using-api?slide=23

    View Slide

  20. E2Eテスト
    ユーザと同じようにブラウザを操作し、システム全体を通して期待ど
    おりの動作をしているかを確認する
    ● Puppeteer を採用
    ● ハッピーパス(正常系の代表操作) の動作を担保
    20
    関連資料: 新規プロダクトの開発速度と品質の両立を支える自動テスト
    https://speakerdeck.com/noriharu3/automation-testing-supports-both-development-speed-and-quality-of-new-product?slide=23

    View Slide

  21. 21
    ● バージョンアップ環境の準備

    ● テストによる品質担保

    ● リリース

    ● メンバーのローカル環境更新

    ・Oracle Critical Patch Updates の公開
    ・脆弱性対応バージョン のリリース

    View Slide

  22. リリースモジュールの作成
    ● Gitのタグを打つと自動で作成する
    ○ Java プログラムのビルド
    ○ Docker イメージのビルド 〜 プッシュ
    ※継続的デプロイ には対応していない
    22

    View Slide

  23. リリース
    ● イメージをもとにコンテナを起動するだけ
    ○ 何台もあるサーバの1台1台にインストールしていくような作業は不要
    23

    View Slide

  24. リリース
    ● イメージをもとにコンテナを起動するだけ
    ○ 何台もあるサーバの1台1台にインストールしていくような作業は不要
    ● 無停止でリリース可能
    ○ AWS ECS の rolling update で実現
    24

    View Slide

  25. リリース
    ● イメージをもとにコンテナを起動するだけ
    ○ 何台もあるサーバの1台1台にインストールしていくような作業は不要
    ● 無停止でリリース可能
    ○ AWS ECS の rolling update で実現
    ● 無停止 = 顧客への影響が出ない
    ○ 顧客への事前周知が不要
    25

    View Slide

  26. リリース
    ● イメージをもとにコンテナをきどうするだけ
    ○ 何台もあるサーバの1台1台にインストールしていくような作業は不要
    ● 無停止でリリース可能
    ○ AWS ECS の rolling update で実現
    ● 無停止 = 顧客への影響が出ない
    ○ 顧客への事前周知が不要
    → 開発/インフラチームの準備が整い次第リリースできる!!
    26

    View Slide

  27. 27
    ● バージョンアップ環境の準備

    ● テストによる品質担保

    ● リリース

    ● メンバーのローカル環境更新

    ・Oracle Critical Patch Updates の公開
    ・脆弱性対応バージョン のリリース

    View Slide

  28. Java のバージョン管理ツール(SDKMAN!) を採用
    ● バージョンアップ担当者
    ○ Git リポジトリの設定ファイル(.sdkmanrc)を更新
    ● メンバー
    ○ SDKMAN! から Java のインストールを促されるので、そのコマンドを実
    行するだけ 28
    メンバーのローカル環境更新
    # Enable auto-env through the sdkman_auto_env config
    # Add key=value pairs of SDKs to use below
    - java=17.0.3-amzn
    + java=17.0.4-amzn

    View Slide

  29. まとめ
    29

    View Slide

  30. まとめ
    ● コンテナやパッケージ管理ツールを採用
    ○ バージョンアップ作業が簡単
    ○ 本番環境への反映もコンテナを置き換えるだけ
    ● 自動テストで品質担保
    ○ 品質担保にかかるリソースを削減
    ○ テスト品質が実施者に依存せず、毎回一定水準を担保できる
    ● 無停止でリリース
    ○ 顧客影響が無いため、ビジネスサイドから理解を得やすい
    30

    View Slide