「いきなり{非機能要求グレード,PCIDSS}担当にさせられた！どうする！？」

株式会社パイプライン
代表取締役濱田康貴

クラウドインテグレーション
IaaS環境設計・構築
SaaS環境設計・構築
運用改善コンサルティング
テクニカルライティング
2
商号株式会社パイプライン ( 英文名 PIPELINE Co., Ltd. )
代表者濱田康貴
所在地東京都品川区小山4-4-7 コスモ武蔵小山ビル8F
設立 2017年8月
電気通信事業者 A-29-16089
WEBサイト https://pipelinejp.com/
事業領域会社概要

3@nullpopopo
@pipelinejp
@nullpopopo
@togoshiginger
@nullpopopo@heisha5f
@pipelinejp_com @pipelinejpcom

4
最初に宣伝
させてください
いきなり{非機能要求グレード,PCIDSS}担当にさせられた！どうする！？

Software Design2020年3月号
ヤマハ特集執筆中しました！
皆さん、読む用保存用布教用と3冊
購入していただけると嬉しいです！

非機能要求グレード

運用設計の品質向上に「非機能要求グレード」を活用しよう
 非機能要求グレードは、システム基盤の発注者要求を見える化する非機能要求グレード検討会から生まれたツール群
 2018年4月25日に公開された版が最新版
https://www.ipa.go.jp/sec/reports/20180425.html

機能要求と非機能要求の違い

機能要求と非機能要求の違い
 機能要求を満たす #とは
 利用者の能動的な要求を実現するアプリケーション
 モノによってはハードウェアが実現することも (そのハードウェアでもソフトウェアが動いている)
 機能要求が満たされないと...
 目に見えるバグとして顕在化されやすい
 そこにあるべき機能がない
 思っていたのと違う動きをする
 etc...
 非機能要求 #とは
 次のページで
 非機能要求の抜け漏れがあると
 性能劣化
 セキュリティインシデント
 バックアップデータの不在やリストア失敗
 etc...

非機能要求グレード2018 活用シートを見てみよう
 非機能要求グレード2018には約240の項目がある
 大項目は以下の通り
 可用性
 性能・拡張性
 運用・保守性
 移行性
 セキュリティ
 システム環境・エコロジー

このサービスをどう運用するのか？という
要件レベル(可用性)を、メトリクスとレベ
ルの掛け算で定義する

備考欄には、IPAが考えた運用レベルに
ついての考えかたが書いてあるので参考
になる

システムやサブシステムなどの単位で、社会的
影響ごとに運用レベルを分けることも想定さ
れているので、ｵﾝｼｬｧのガバナンスルールや利
用者(社内・社外etc...)への影響度によって
適宜使いわけすることができる

https://www.school.ctc-g.co.jp/columns/hamada/hamada13.html

顧客やステークホルダーは大抵、機能要件にしか興味がない
 稀に非機能要件 (特にセキュリティ)に興味を示すが...
 責任回避欲求
 過去にほんとうにインシデントがあった
 など、あまりポジティブではない理由がある...
非機能要件について設計したい...どうやって予算取りする？
 IPAが推してるのだから、と錦の御旗にしよう
 特殊な事情を除き、基本的に網羅性は高い
 しかも無理やりすべてを当てはめなくてもよい
 「いい感じにやっといて」は危険
 せめて「この中からコレとコレをチョイスしましたー」って提案しよう
非機能要求グレードの活用方法 (現場目線)

ITILについてちょっとだけ

ITIL #とは
 Information Technology Infrastructure
Library（ITIL）とは、ITサービスマネジメントにおけ
るベストプラクティス（成功事例）をまとめた書籍群。
1989年にイギリス政府のCCTAによって公表された。
ITILの読み方は「アイティル」、「アイティーアイエル」な
どがある。ITサービス全体においてデファクトスタンダー
ドとなりつつあり、重要な位置付けとなっている。
 ITIL 5つのアプローチ
 サービスストラテジ
→ ITサービスの戦略を立案する
 サービスデザイン
→ ITサービスを設計する
 サービストランジション
→ ITサービスを本番環境へ移行する
 サービスオペレーション
→ ITサービスを運用する
 継続的サービス改善
※ Wikipediaより引用

推薦図書紹介
 沢渡あまね (著) 新人ガール ITIL使って業務プロセ
ス改善します!
 トップダウンで業務プロセス改善を求められた、どうしよ
う？という方におすすめ
 IT知識不要！って書いてあるけど本当に不要だった
 読みすすめるにあたって、不要という意味です
 顧客側の担当者さんには有用

推薦図書紹介
 日本ビジネスシステムズ株式会社 (著), 近藤誠司
(著) 運用設計の教科書～現場で困らないITサービ
スマネジメントの実践ノウハウ
 運用設計書そのものの書き方、運用設計書がなぜ必要
とされるのかを学ぶのに有用
 プロジェクトのフェーズごとに何をしたらよいか、どういうア
ウトプットをすればよいのかが丁寧に書かれている
 ITILそのものの理解、というよりも、ITILをどうやって運
用に落とし込んでいくか、という観点で読むと非常に腹落
ちする

え!?ワイが明日からPCI DSSの
要件定義を?

え!?ワイが明日からPCI DSSの要件定義を?
PCI DSS #とは
 もともとはクレジットカードブランドがそれぞれにセキュリ
ティ基準を決めていた
 加盟店にとっては面倒だった
 American Express、Discover、JCB、
MasterCard、VISAが共同で設立したPCI
SSC(Payment Card Industry Security
Standards Council)によって、クレジットカード業
界のセキュリティ基準としてはじまった。
 導入が必要な企業
 カード情報を「保存、処理、または伝送する」企業である
カード加盟店、銀行、決済代行などを行うサービス・プロ
バイダー
 年間のカード取引量に応じてPCI DSS準拠する必要
がある
 カード取引量がPCI DSS準拠の基準に満たさなくても、
各カードブランドが制定しているセキュリティ基準プログ
ラムに準拠する必要がある
 具体例
金融業：クレジットカード会社、クレジットカード発行金融機関
流通業：大手百貨店、スーパー、量販店、鉄道、航空会社
通信/メディア/公共：携帯電話会社、通信会社、ユーティリティ、新聞
製造業：石油業界他
※ 引用元
PCIDSSとは｜日本カード情報セキュリティ協議会
https://www.jcdsc.org/pci_dss.php

PCI DSS基準の資料をダウンロードしよう
https://ja.pcisecuritystandards.org/minisite/env2/

PCI DSS基準の資料をダウンロードしよう

PCI DSS 12の要件
12の要件

PCI DSS 12の要件
要件 1 : カード会員データを保護するために、ファイアウォールをインストールして構成を維持する
要件 2 : システムパスワードおよび他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない
要件 3 : 保存されるカード会員データを保護する
要件 4 : オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する
要件 5 : すべてのシステムをマルウェアから保護し、ウイルス対策ソフトウェアまたはプログラムを定期的に更新する
要件 6 : 安全性の高いシステムとアプリケーションを開発し、保守する
要件 7 : カード会員データへのアクセスを、業務上必要な範囲内に制限する
要件 8 : システムコンポーネントへのアクセスを識別・認証する
要件 9 : カード会員データへの物理アクセスを制限する
要件 10: ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
要件 11: セキュリティシステムおよびプロセスを定期的にテストする。
要件 12: すべての担当者の情報セキュリティに対応するポリシーを維持する。

PCI DSS ドキュメントの読み方

基本的な考えかた
 要件に対してテスト手順があり、そのヒントとしてガイダンスがある
要件 PCI DSSとして遵守してほしい要件
テスト手順要件を遵守するためにするべきこと、およびその品質目標
ガイダンステスト手順をクリアしないとどうなるか、あるいはテスト手順の適用
範囲などのヒント

 PCI DSS要件
 1.3.4 カード会員データ環境からインターネットへの未
承認の発信トラフィックを禁止する。
 テスト手順
 1.3.4ファイアウォール/ルーター構成を検査し、カード
会員データ環境からインターネットへの発信トラフィック
が明示的に承認されていることを確認する。
 ガイダンス
 カード会員データ環境から発信されるすべてのトラフィッ
クを評価して、発信トラフィックが確立・承認されたルー
ルに確実に従うようにする必要があります。接続を検査し
て、許可された通信のみにトラフィックを制限する必要が
あります（送信元/宛先のアドレス/ポートの制限やコン
テンツのブロックなど）。
 実装例 (あくまで例題です)
 カード会員データ環境はDMZに置かず、別セグメントに
置く
 カード会員データ環境のインスタンスは、インターネットへ
のルーティングを行わない
 ただし、dnf updateやWindows updateはVPN経
由で本社のリポジトリサーバーやWSUSサーバーに対して
接続できるようにする

まとめ
 非機能要求グレードも、ITILも、PCI DSSも、“トップダウン”で
導入したほうがよいです
 導入契機、品質目標 (どこまでやったらよいのか) は、これらを錦の御
旗にしよう
 いいとこ取りで導入してもOK
 特殊な事情を除いてこれらが「上振れしない工数」「網羅性の上限」と
考えても差し支えない
 これらを愚直に導入するだけでも、運用でカバー (イレギュラー) は
かなり削減できるはず

「いきなり{非機能要求グレード,PCIDSS}担当にさせられた！どうする！？」

More Related Content

What's hot

More from Yasutaka Hamada

Recently uploaded

「いきなり{非機能要求グレード,PCIDSS}担当にさせられた！どうする！？」