Successfully reported this slideshow.
Your SlideShare is downloading. ×

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

Ad

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

Ad

クラウドインテグレーション
IaaS環境設計・構築
SaaS環境設計・構築
運用改善コンサルティング
テクニカルライティング
2
商号 株式会社パイプライン ( 英文名 PIPELINE Co., Ltd. )
代表者 濱田 康貴
所在地 東京...

Ad

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

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Check these out next

1 of 34 Ad
1 of 34 Ad

More Related Content

Slideshows for you (19)

More from Yasutaka Hamada (20)

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

  1. 1. 株式会社パイプライン 代表取締役 濱田康貴
  2. 2. クラウドインテグレーション IaaS環境設計・構築 SaaS環境設計・構築 運用改善コンサルティング テクニカルライティング 2 商号 株式会社パイプライン ( 英文名 PIPELINE Co., Ltd. ) 代表者 濱田 康貴 所在地 東京都品川区小山4-4-7 コスモ武蔵小山ビル8F 設立 2017年8月 電気通信事業者 A-29-16089 WEBサイト https://pipelinejp.com/ 事業領域 会社概要
  3. 3. 3@nullpopopo @pipelinejp @nullpopopo @togoshiginger @nullpopopo@heisha5f @pipelinejp_com @pipelinejpcom
  4. 4. 4 最初に宣伝 させてください いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  5. 5. いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  6. 6. Software Design2020年3月号 ヤマハ特集執筆中しました! 皆さん、読む用 保存用 布教用と3冊 購入していただけると嬉しいです!
  7. 7. 非機能要求グレード いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  8. 8. 運用設計の品質向上に「非機能要求グレード」を活用しよう  非機能要求グレードは、システム基盤の発注者要求を見える化する非機能要求グレード検討会から生まれたツール群  2018年4月25日に公開された版が最新版 いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? https://www.ipa.go.jp/sec/reports/20180425.html
  9. 9. 機能要求と非機能要求の違い いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  10. 10. 機能要求と非機能要求の違い  機能要求を満たす #とは  利用者の能動的な要求を実現するアプリケーション  モノによってはハードウェアが実現することも (そのハードウェアでもソフトウェアが動いている)  機能要求が満たされないと...  目に見えるバグとして顕在化されやすい  そこにあるべき機能がない  思っていたのと違う動きをする  etc...  非機能要求 #とは  次のページで  非機能要求の抜け漏れがあると  性能劣化  セキュリティインシデント  バックアップデータの不在やリストア失敗  etc... いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  11. 11. 非機能要求グレード2018 活用シート を見てみよう  非機能要求グレード2018には約240の項目がある  大項目は以下の通り  可用性  性能・拡張性  運用・保守性  移行性  セキュリティ  システム環境・エコロジー いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  12. 12. 非機能要求グレード2018 活用シート を見てみよう いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  13. 13. 非機能要求グレード2018 活用シート を見てみよう いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? このサービスをどう運用するのか?という 要件 レベル(可用性)を、メトリクスとレベ ルの掛け算で定義する
  14. 14. 非機能要求グレード2018 活用シート を見てみよう いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? 備考欄には、IPAが考えた運用レベルに ついての考えかたが書いてあるので参考 になる
  15. 15. 非機能要求グレード2018 活用シート を見てみよう いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? システムやサブシステムなどの単位で、社会的 影響ごとに運用レベルを分けることも想定さ れているので、オンシャァのガバナンスルールや利 用者(社内・社外etc...)への影響度によって 適宜使いわけすることができる
  16. 16. いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? https://www.school.ctc-g.co.jp/columns/hamada/hamada13.html 非機能要求グレード2018 活用シート を見てみよう
  17. 17. いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? 顧客やステークホルダーは大抵、機能要件 にしか興味がない  稀に非機能要件 (特にセキュリティ)に興味を示すが...  責任回避欲求  過去にほんとうにインシデントがあった  など、あまりポジティブではない理由がある... 非機能要件 について設計したい...どうやって予算取りする?  IPAが推してるのだから、と錦の御旗にしよう  特殊な事情を除き、基本的に網羅性は高い  しかも無理やりすべてを当てはめなくてもよい  「いい感じにやっといて」は危険  せめて「この中からコレとコレをチョイスしましたー」って提案しよう 非機能要求グレードの活用方法 (現場目線)
  18. 18. ITILについてちょっとだけ いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  19. 19. ITILについてちょっとだけ ITIL #とは  Information Technology Infrastructure Library(ITIL)とは、ITサービスマネジメントにおけ るベストプラクティス(成功事例)をまとめた書籍群。 1989年にイギリス政府のCCTAによって公表された。 ITILの読み方は「アイティル」、「アイティーアイエル」な どがある。ITサービス全体においてデファクトスタンダー ドとなりつつあり、重要な位置付けとなっている。  ITIL 5つのアプローチ  サービスストラテジ → ITサービスの戦略を立案する  サービスデザイン → ITサービスを設計する  サービストランジション → ITサービスを本番環境へ移行する  サービスオペレーション → ITサービスを運用する  継続的サービス改善 いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? ※ Wikipediaより引用
  20. 20. ITILについてちょっとだけ 推薦図書紹介  沢渡あまね (著) 新人ガール ITIL使って業務プロセ ス改善します!  トップダウンで業務プロセス改善を求められた、どうしよ う?という方におすすめ  IT知識不要!って書いてあるけど本当に不要だった  読みすすめるにあたって、不要という意味です  顧客側の担当者さんには有用 いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  21. 21. ITILについてちょっとだけ 推薦図書紹介  日本ビジネスシステムズ株式会社 (著), 近藤 誠司 (著) 運用設計の教科書 ~現場で困らないITサービ スマネジメントの実践ノウハウ  運用設計書そのものの書き方、運用設計書がなぜ必要 とされるのかを学ぶのに有用  プロジェクトのフェーズごとに何をしたらよいか、どういうア ウトプットをすればよいのかが丁寧に書かれている  ITILそのものの理解、というよりも、ITILをどうやって運 用に落とし込んでいくか、という観点で読むと非常に腹落 ちする いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  22. 22. え!?ワイが明日からPCI DSSの 要件定義を?
  23. 23. え!?ワイが明日からPCI DSSの要件定義を? PCI DSS #とは  もともとはクレジットカードブランドがそれぞれにセキュリ ティ基準を決めていた  加盟店にとっては面倒だった  American Express、Discover、JCB、 MasterCard、VISAが共同で設立したPCI SSC(Payment Card Industry Security Standards Council)によって、クレジットカード業 界のセキュリティ基準としてはじまった。  導入が必要な企業  カード情報を「保存、処理、または伝送する」企業である カード加盟店、銀行、決済代行などを行うサービス・プロ バイダー  年間のカード取引量に応じてPCI DSS準拠する必要 がある  カード取引量がPCI DSS準拠の基準に満たさなくても、 各カードブランドが制定しているセキュリティ基準プログ ラムに準拠する必要がある  具体例 いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? 金融業:クレジットカード会社、クレジットカード発行金融機関 流通業: 大手百貨店、スーパー、量販店、鉄道、航空会社 通信/メディア/公共:携帯電話会社、通信会社、ユーティリティ、新聞 製造業:石油業界 他 ※ 引用元 PCIDSSとは|日本カード情報セキュリティ協議会 https://www.jcdsc.org/pci_dss.php
  24. 24. え!?ワイが明日からPCI DSSの要件定義を? PCI DSS基準の資料をダウンロードしよう いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? https://ja.pcisecuritystandards.org/minisite/env2/
  25. 25. え!?ワイが明日からPCI DSSの要件定義を? PCI DSS基準の資料をダウンロードしよう いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? https://ja.pcisecuritystandards.org/minisite/env2/
  26. 26. いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? え!?ワイが明日からPCI DSSの要件定義を? PCI DSS基準の資料をダウンロードしよう
  27. 27. いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? え!?ワイが明日からPCI DSSの要件定義を? PCI DSS 12の要件 12の要件
  28. 28. いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? え!?ワイが明日からPCI DSSの要件定義を? PCI DSS 12の要件 要件 1 : カード会員データを保護するために、ファイアウォールをインストールして構成を維持する 要件 2 : システムパスワードおよび他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない 要件 3 : 保存されるカード会員データを保護する 要件 4 : オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する 要件 5 : すべてのシステムをマルウェアから保護し、ウイルス対策ソフトウェアまたはプログラムを定期的に更新する 要件 6 : 安全性の高いシステムとアプリケーションを開発し、保守する 要件 7 : カード会員データへのアクセスを、業務上必要な範囲内に制限する 要件 8 : システムコンポーネントへのアクセスを識別・認証する 要件 9 : カード会員データへの物理アクセスを制限する 要件 10: ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する 要件 11: セキュリティシステムおよびプロセスを定期的にテストする。 要件 12: すべての担当者の情報セキュリティに対応するポリシーを維持する。
  29. 29. いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? え!?ワイが明日からPCI DSSの要件定義を? PCI DSS ドキュメントの読み方
  30. 30. いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!? え!?ワイが明日からPCI DSSの要件定義を? PCI DSS ドキュメントの読み方 基本的な考えかた  要件に対してテスト手順があり、そのヒントとしてガイダンスがある 要件 PCI DSSとして遵守してほしい要件 テスト手順 要件を遵守するためにするべきこと、およびその品質目標 ガイダンス テスト手順をクリアしないとどうなるか、あるいはテスト手順の適用 範囲などのヒント
  31. 31. え!?ワイが明日からPCI DSSの要件定義を? PCI DSS ドキュメントの読み方  PCI DSS要件  1.3.4 カード会員データ環境からインターネットへの未 承認の発信トラフィックを禁止する。  テスト手順  1.3.4ファイアウォール/ルーター構成を検査し、カード 会員データ環境からインターネットへの発信トラフィック が明示的に承認されていることを確認する。  ガイダンス  カード会員データ環境から発信されるすべてのトラフィッ クを評価して、発信トラフィックが確立・承認されたルー ルに確実に従うようにする必要があります。接続を検査し て、許可された通信のみにトラフィックを制限する必要が あります(送信元/宛先のアドレス/ポートの制限やコン テンツのブロックなど)。  実装例 (あくまで例題です)  カード会員データ環境はDMZに置かず、別セグメントに 置く  カード会員データ環境のインスタンスは、インターネットへ のルーティングを行わない  ただし、dnf updateやWindows updateはVPN経 由で本社のリポジトリサーバーやWSUSサーバーに対して 接続できるようにする いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  32. 32. いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  33. 33. まとめ  非機能要求グレードも、ITILも、PCI DSSも、“トップダウン”で 導入したほうがよいです  導入契機、品質目標 (どこまでやったらよいのか) は、これらを錦の御 旗にしよう  いいとこ取りで導入してもOK  特殊な事情を除いてこれらが「上振れしない工数」「網羅性の上限」と 考えても差し支えない  これらを愚直に導入するだけでも、運用でカバー (イレギュラー) は かなり削減できるはず いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?
  34. 34. いきなり{非機能要求グレード,PCIDSS}担当にさせられた!どうする!?

×