PCI DSSの観点から見た セキュアなJavaアプリケーション開発 JJUG CCC 2024 Spring 2024-06-16 南慶彦

自己紹介 ● 名前: 南 慶彦 ○ x: @ym1990 ○ GitHub: nannany ● 経歴 ○ TIS株式会社(2015~2021) ○ STORES株式会社(2021~現在) ■ PCI DSS監査を3回経験 ● Java, Springの組み合わせでWebアプリケーション作 成することが多い 2

話すこと ● そもそもPCI DSSとは何か？ ● PCI DSSにはセキュアなアプリケーション開発に関するアドバイスが散りばめられ ている。それらを実体験を交えて紹介する ○ 適切なコードレビュー ○ シフトレフト ○ ライブラリの脆弱性管理 ● クレジットカード系システムに限定されないプロセスであるので、この紹介がセキュ アなアプリケーション開発の一助となれば幸い 3

PCI DSSとは？ ● クレジットカード業界のデータセキュリティ標準 (Payment Card Industry Data Security Standards) ● 運営主体はPCI SSC(Payment Card Industory Security Standards Council)。 PCI SSCはクレジットカードの5大ブランド(Visa、Mastercard、JCB、American Express、Diners Club International)によって2006年に設立 ● クレジットカードを取り扱う会社は PCI DSSに準拠する必要がある ○ 割賦販売法のクレジットカードを取り扱う事業者が行う必要な措置 にあたる ○ 5大ブランドもPCI DSSへの準拠を要請している 4

PCI DSSに準拠するには？ ● QSA(Qualified Security Assessor)による訪問審査を受ける ○ QSA=PCI SSCに認定された評価者 ○ 12要件、約400項目を遵守していることを証明する ○ 訪問審査は丸々5日かけて行われる 
 5

PCI DSS要件のイメージ(1.2.1を例に) ● 要件1.2.1: NSC(ネットワークセキュリティコントロール )ルールセットの構成基準が ○ 定義されている ○ 実装されている ○ 維持されている ● テスト手順1.2.1.a: NSC ルールセットの構成基準を調べ、その基準がこの要件で指定された すべての要素に準拠していることを確認する。 ● テスト手順1.2.1.b: NSC ルールセットの構成設定を調べ、ルールセットが構成基準に従って実 装されていることを確認する。 6 ● 要件を満たす構成基準、構成基準に即した実装、それらが運用されていることを監 査される

他のセキュリティ規格との違い ● セキュリティに関する規格として、他にもISO/IEC27001(いわゆるISMS)などがあ る。PCI DSSは要件の具体性 に特徴がある ○ 防ぐべき脆弱性を明示するためにSQLやLDAPといった技術用語が平然と出 てくる ○ パスワードに関する指定について、文字数/文字種の決まりがある ● 具体的であるがため、即実行しやすいアドバイスが多い 7 SQL、LDAP、XPath、またはその他のコマンド、パラメータ、オブジェクト、障害、インジェクションタイ プの欠陥を含む、インジェクション攻撃 (要件6.2.4より抜粋) (パスワードは)12 文字以上(またはシステムが 12 文字に対応していない場合は、8 文字以上)であ ること。数字とアルファベットの両方が含まれていること。 (要件8.3.6より抜粋)

アプリケーション実装に関わる要件 ● PCI DSSでは、様々なレイヤーでの対策を組み合わせている ● アプリケーション開発に密接に関わるのは、6章 安全なシステムおよびソフトウェア の開発と維持 ● 今回は6.2, 6.3の要件に着目する ○ 6.2 オーダーメイド、カスタムソフトは安全に開発されます ■ 適切なコードレビュー ■ シフトレフト ○ 6.3 セキュリティ上の脆弱性を特定し、対処している ■ ライブラリの脆弱性管理 8

1. 適切なコードレビュー ● 要件6.2.3では、手動コードレビューの実施を求める ● その目的は、セキュリティに影響を与えるコードが本番にリリースされるのを防ぐこ と 9 コード変更はコードレビュー技術やセキュアコーディングの実践に精通した、元のコード作成者以外 の個人によってレビューされる。(要件6.2.3.1より抜粋)

1. 適切なコードレビュー(グッドプラクティス) ● 一度に少量のコードしかレビューしない というアドバイスは重要で、目安として500 行を超えるレビューは有効なものになりにくい 10 コードレビューは疲れる作業です。このため、レビュアーが一度に少量のコードしかレビューしない場 合に最も効果的です。(6.2.3.1 グッドプラクティスより抜粋)

1. 適切なコードレビュー(レビュー項目) ● Spring等のFWを利用してアプリケーションを作っていると、大概の脆弱性はFWで 対応してくれるので、それらを正しく使うことが重要 11 ソフトウェアが外部コンポーネントの機能 (ライブラリ、フレームワーク、API など)を安全に使用してい ることを確認する。(要件6.2.3より一部抜粋) ● よく問題になるのは、ログに機密データが載ること、業務特有のこと(ex: staffは一 部だけ見れて、ownerは全て見れる) 機密データがログに残らないよう、ログが正しく使用されているかを確認する。 論理的な脆弱性を検出するために、アプリケーションの動作をチェックすること。 (要件6.2.3より一部抜粋)

2. シフトレフト 12 脆弱なコードにつながる一般的なエラーをソフトウェア開発プロセスのできるだけ早い段階で検出ま たは防止することで、そのようなエラーが本番環境に出て危険にさらされる確率を低くすることができ ます。(中略)この哲学は、「シフトレフト」と呼ばれることもあります。(6.2.4の目的より抜粋) セキュリティ・バイ・デザイン導入指南書

2. シフトレフト(CI/CD) 13 手法としては、開発サイクルの初期にコードをチェックインする際にコードをスキャンし、脆弱性が存 在しないことを確認する自動化されたプロセスやプラクティスがあります。 (要件6.2.4の事例紹介より 抜粋) セキュリティ・バイ・デザイン導入指南書 ● 一度仕組みを作れば安心を得られる ○ セキュリティツールの実施漏れを防げる ○ セキュリティ知識が薄いメンバーでも同様にツール実施できる ● どのチェックを有効にするかの判別が難しい。。 ○ 仕様を満たすためには破らざるを得ないチェックの判別などはセキュリティ知 識が必要

3. ライブラリの脆弱性管理 ● 要件6.3.3では、利用しているライブラリなどから脆弱性が見つかった場合に、速や かに対応することを問われる 14 すべてのシステムコンポーネントは、以下のように適用可能なセキュリティパッチ /アップデートをイン ストールすることで、既知の脆弱性から保護されている (要件6.3.3より一部抜粋)

3. ライブラリの脆弱性管理(Apache Log4jの事例) ● 2021年12月末にApache Log4jの脆弱性 CVE-2021-44228 が話題に ○ 深刻度のレベルは最も高い Critical ● Spring Bootの依存関係の中にもLog4jは含まれていたので、Springの公式ブログ でも対応ガイダンスが発表された ● このように、ライブラリ側に脆弱性が見つかった場合には、そのバージョンを上げる 必要がある 15

3. ライブラリの脆弱性管理(状況把握) ● 自分の作っているソフトウェアが、そもそも何に依存しているかを把握する必要があ る ● Amazon Inspector などで容易に管理することができる 16 サードパーティソフトウェアコンポーネントのインベントリを維持し、脆弱性およびパッチ管理を容易に する。(要件6.3.2より抜粋)

3. ライブラリの脆弱性管理(現場のつらみ1) ● ex1) SpringBootでバージョン管理をしているライブラリのうちのどれかに脆弱性が でた場合、SpringBoot自体の更新をしたいが、諸々のバージョンが上がってしまう ので怖い。。 ● 自動テストを充実して、ライブラリアップデートをカジュアルにできるようにすること が、セキュリティにも貢献する 17

3. ライブラリの脆弱性管理(現場のつらみ2) ● ex2) メンテナンスが放棄されたOSSが利用しているライブラリに脆弱性が発覚した 場合、forkする、別のOSSライブラリを使うなど考える必要がある ● OSS選定の際には、メンテナンスの状況を確認した方が良い 18

まとめ ● PCI DSSの要件から、アプリケーション開発プロセスに関わるアドバイスを抽出す ると、下記のよう ○ 適切なコードレビュー ■ 一度に行うレビューの量は少量を保つこと ■ FWを適切に使うこと、秘匿情報がログetcに出てないことなどに気をつけ る ○ シフトレフト ■ 開発プロセスにセキュリティテストの自動化を組み込む ○ ライブラリの脆弱性管理 ■ どのライブラリに依存しているか即分かる状況を整えること ■ カジュアルにライブラリアップデートできる状況を整えること 19