JIS Q 27002:2014 情報技術―セキュリティ技術―情報セキュリティ管理策の実践のための規範 | ページ 13

58
Q 27002 : 2014 (ISO/IEC 27002 : 2013)
  ソフトウェア及びシステムの開発のための規則は,組織内において確立し,開発に対して適用すること
が望ましい。
実施の手引
  セキュリティに配慮したサービス,アーキテクチャ,ソフトウェア及びシステムを構築するには,セキ
ュリティに配慮した開発が必要となる。セキュリティに配慮した開発のための方針には,次の側面を考慮
することが望ましい。
a) 開発環境のセキュリティ
b) ソフトウェア開発のライフサイクルにおける,次に関わるセキュリティに関する手引
  1) ソフトウェア開発の方法論におけるセキュリティ
  2) 用いる各プログラミング言語について定めた,セキュリティに配慮したコーディングに関する指針
c) 設計段階におけるセキュリティ要求事項
d) プロジェクトの開発の節目ごとにおけるセキュリティの確認項目
e) セキュリティが保たれたリポジトリ
f)  版の管理におけるセキュリティ
g) アプリケーションのセキュリティに関して必要な知識
h) ぜい弱性を回避,発見及び修正するに当たっての開発者の能力
  開発に適用される標準類が知られていない可能性がある場合,又は現行の最適な慣行に整合していなか
った場合には,新規開発する場合及びコードを再利用する場合の両方に,セキュアプログラミング技術を
用いることが望ましい。セキュリティに配慮したコーディングに関する標準類を考慮し,該当する場合に
は,その使用を義務付けることが望ましい。開発者は,これらの標準類の使用及び試験について訓練を受
けることが望ましく,また,コードレビューによって標準類の使用を検証することが望ましい。
  開発を外部委託した場合,組織は,その外部関係者がセキュリティに配慮した開発のための規則を順守
していることの保証を得ることが望ましい(14.2.7参照)。
関連情報
  開発は,オフィスのアプリケーション,スクリプト記述,ブラウザ,データベースなどの,アプリケー
ションにおいて行われることもある。
14.2.2 システムの変更管理手順
管理策
  開発のライフサイクルにおけるシステムの変更は,正式な変更管理手順を用いて管理することが望まし
い。
実施の手引
  初期設計段階からその後の全ての保守業務に至るまで,システム,アプリケーション及び製品の完全性
を確実にするため,正式な変更管理手順を文書化し,実施することが望ましい。新しいシステムの導入及
び既存システムに対する重要な変更は,文書化,仕様化,試験,品質管理及び管理された実装からなる正
式な手続に従うことが望ましい。
  この手続には,リスクアセスメント,変更の影響分析及び必要なセキュリティ管理策の仕様化を含むこ
とが望ましい。この手続は,既存のセキュリティ及び管理手順が損なわれないこと,サポートプログラマ
によるシステムへのアクセスはその作業に必要な部分に限定されること,並びにいかなる変更に対しても
正式な合意及び承認が得られていることを確実にすることが望ましい。

――――― [JIS Q 27002 pdf 61] ―――――

                                                                                             59
                                                              Q 27002 : 2014 (ISO/IEC 27002 : 2013)
  実施可能な場合には,アプリケーション及びその運用に関する変更管理手順を統合することが望ましい
(12.1.2参照)。変更管理手順には,次の事項が含まれることが望ましいが,これらに限らない。
a) 合意された認可レベルの記録を維持する。
b) 変更は,認可されている利用者によって提出されることを確実にする。
c) 変更によって管理策及び完全性に関する手順が損なわれないことを確実にするために,管理策及び手
    順をレビューする。
d) 修正を必要とする全てのソフトウェア,情報,データベース及びハードウェアを特定する。
e) セキュリティ上の既知の弱点を最少化するために,セキュリティが特に重要とされるコードを特定し,
    これを点検する。
f)  作業を開始する前に,提案の詳細について正式な承認を得る。
g) 変更を実施する前に,認可されている利用者がその変更を受け入れることを確実にする。
h) システムに関する一式の文書が各変更の完了時点で更新されること,及び古い文書類は記録・保管さ
    れるか又は処分されることを確実にする。
i)  全てのソフトウェアの更新について,版数の管理を維持する。
j)  全ての変更要求の監査証跡を維持・管理する。
k) 操作手順書などの運用文書類(12.1.1参照)及び利用者手順が,適切な状態であるように,必要に応
    じて変更することを確実にする。
l)  変更の実施は最も適切な時期に行い,関係する業務処理を妨げないことを確実にする。
関連情報
  ソフトウェアの変更が運用環境に,また運用環境がソフトウェアの変更に影響を与える可能性がある。
  運用環境及び開発環境から分離された環境で新しいソフトウェアを試験することは,良い慣行である
(12.1.4参照)。これは,新しいソフトウェアを管理し,試験目的のために用いられている運用情報に追加
の保護を与える手段を提供する。これは,パッチ,サービスパック及びその他の更新を含んでいることが
望ましい。自動的な更新を考慮する場合は,システムの完全性及び可用性に対するリスクと,更新を迅速
化することの利点とを,比較・検討することが望ましい。更新によっては,重要なアプリケーションの障
害を起こす可能性があるので,自動的な更新は,重要なシステムでは用いないことが望ましい。
14.2.3 オペレーティングプラットフォーム変更後のアプリケーションの技術的レビュー
管理策
  オペレーティングプラットフォームを変更するときは,組織の運用又はセキュリティに悪影響がないこ
とを確実にするために,重要なアプリケーションをレビューし,試験することが望ましい。
実施の手引
  この手続には,次の事項を含むことが望ましい。
a) オペレーティングプラットフォームの変更によって,アプリケーションの機能及び処理の完全性が損
    なわれていないことを確実にするために,これらに関係する手続きをレビューする。
b) 実施前に適切な試験及びレビューを行っても間に合うように,オペレーティングプラットフォームの
    変更を通知することを確実にする。
c) 事業継続計画(箇条17参照)に対して,適切な変更がなされることを確実にする。
関連情報
  オペレーティングプラットフォームには,オペレーティングシステム,データベース及びミドルウェア
プラットフォームも含む。管理策は,アプリケーションの変更にも適用することが望ましい。

――――― [JIS Q 27002 pdf 62] ―――――

60
Q 27002 : 2014 (ISO/IEC 27002 : 2013)
14.2.4 パッケージソフトウェアの変更に対する制限
管理策
  パッケージソフトウェアの変更は,抑止し,必要な変更だけに限ることが望ましい。また,全ての変更
は,厳重に管理することが望ましい。
実施の手引
  可能な限り,そして実行可能な場合には,業者が供給するパッケージソフトウェアは,変更しないで用
いることが望ましい。パッケージソフトウェアの変更が必要な場合は,次の事項を考慮するのが望ましい。
a) 組み込まれている機能及び処理の完全性が損なわれるリスク
b) 業者の同意の取得
c) 標準的なプログラム更新として,業者から必要とする変更が得られる可能性
d) 変更の結果として,将来のソフトウェアの保守に対して,組織が責任を負うようになるかどうかの影
    響
e) 用いている他のソフトウェアとの互換性
  変更が必要な場合,原本のソフトウェアは保管し,指定された複製に対して変更を適用することが望ま
しい。全ての認可されたソフトウェアに対して最新の承認したパッチ及びアプリケーションの更新を導入
していることを確実にするために,ソフトウェアの更新管理手続を実施することが望ましい(12.6.1参照)。
将来のソフトウェア更新において,必要な場合には,再び適用できるように,全ての変更は,十分に試験
し,文書化することが望ましい。必要な場合には,変更は,独立した評価機関による試験を受け,正当性
を証明してもらうことが望ましい。
14.2.5 セキュリティに配慮したシステム構築の原則
管理策
  セキュリティに配慮したシステムを構築するための原則を確立し,文書化し,維持し,全ての情報シス
テムの実装に対して適用することが望ましい。
実施の手引
  セキュリティに配慮したシステム構築の原則に基づき,情報システムの構築手順を確立し,文書化し,
組織の情報システム構築活動に適用することが望ましい。セキュリティは,情報セキュリティの必要性と
アクセス性の必要性との均衡を保ちながら,全てのアーキテクチャ層(業務,データ,アプリケーション
及び技術)において設計することが望ましい。新技術は,セキュリティ上のリスクについて分析し,その
設計を既知の攻撃パターンに照らしてレビューすることが望ましい。
  これらの原則及び確立した構築手順は,構築プロセスにおけるセキュリティレベルの向上に有効に寄与
していることを確実にするために,定期的にレビューすることが望ましい。また,これらの原則及び手順
が,新規の潜在的な脅威に対抗するという点で最新であり続けていること,及び適用される技術及びソリ
ューションの進展に適用可能であり続けていることを確実にするために,定期的にレビューすることが望
ましい。
  確立された設計のセキュリティに関するこの原則は,該当する場合には,組織と組織が外部委託した供
給者との間の,契約及び拘束力をもつその他の合意を通じて,外部委託した情報システムにも適用するこ
とが望ましい。組織は,供給者の設計のセキュリティに関する原則が,自身の原則と同様に厳密なもので
あることを確認することが望ましい。
関連情報

――――― [JIS Q 27002 pdf 63] ―――――

                                                                                             61
                                                              Q 27002 : 2014 (ISO/IEC 27002 : 2013)
  アプリケーションの開発手順では,入出力インターフェースをもつアプリケーションの開発に対し,セ
キュリティに配慮した構築技術(セキュアプログラミングなど)を適用することが望ましい。セキュリテ
ィに配慮した構築技術は,利用者認証技術,セキュリティを保ったセッション管理及びデータの妥当性確
認,並びにデバッグコードのサニタイジング及び削除に関する手引となる。
14.2.6 セキュリティに配慮した開発環境
管理策
  組織は,全てのシステム開発ライフサイクルを含む,システムの開発及び統合の取組みのためのセキュ
リティに配慮した開発環境を確立し,適切に保護することが望ましい。
実施の手引
  セキュリティに配慮した開発環境には,システムの開発及び統合に関連する要員,プロセス及び技術も
含む。
  組織は,個々のシステム開発業務に伴うリスクを評価し,特定のシステム開発業務については,次の事
項を考慮して,セキュリティに配慮した開発環境を確立することが望ましい。
a) システムによって処理,保管及び伝送されるデータの取扱いに慎重を要する度合い
b) 適用される外部及び内部の要求事項。例えば,規制又は方針によるもの。
c) 組織によって既に実施されており,システム開発を支えるようなセキュリティ管理策
d) その環境で作業する要員の信頼性(7.1.1参照)
e) システム開発に関連した外部委託の程度
f)  異なる開発環境の分離の必要性
g) 開発環境へのアクセスの制御
h) 開発環境の変更及びそこに保管されたコードに対する変更の監視
i)  セキュリティに配慮した遠隔地でのバックアップの保管
j)  開発環境からの,及び開発環境への,データの移動の管理
  特定の開発環境の保護レベルを決定した後,組織は,セキュリティに配慮した開発手順の中の該当する
プロセスを文書化し,必要とする全ての要員にこれらを提供することが望ましい。
14.2.7 外部委託による開発
管理策
  組織は,外部委託したシステム開発活動を監督し,監視することが望ましい。
実施の手引
  システム開発を外部委託する場合には,組織の外部のサプライチェーン全体にわたり,次の事項を考慮
することが望ましい。
a) 外部委託した内容に関連する使用許諾に関する取決め,コードの所有権及び知的財産権(18.1.2参照)
b) セキュリティに配慮した設計,コーディング及び試験の実施についての契約要求事項(14.2.1参照)
c) 外部の開発者への,承認済みの脅威モデルの提供
d) 成果物の質及び正確さに関する受入れ試験
e) セキュリティ及びプライバシーについて,容認可能な最低限のレベルを定めるためにセキュリティし
    きい(閾)値を用いていることを示す証拠の提出
f)  引渡しに当たって,悪意のある内容(意図的なもの及び意図しないもの)が含まれないよう,十分な
    試験が実施されていることを示す証拠の提出

――――― [JIS Q 27002 pdf 64] ―――――

62
Q 27002 : 2014 (ISO/IEC 27002 : 2013)
g) 既知のぜい弱性が含まれないよう,十分な試験が実施されていることを示す証拠の提出
h) 預託契約に関する取決め。例えば,ソースコードが利用できなくなった場合。
i)  開発のプロセス及び管理策を監査するための契約上の権利
j)  成果物の作成に用いたビルド環境の有効な文書化
k) 適用される法令の順守及び管理の効率の検証については,組織が責任を負うこと
関連情報
  供給者関係についての詳細は,ISO/IEC 27036規格群[21][23]に示されている。
14.2.8 システムセキュリティの試験
管理策
  セキュリティ機能(functionality)の試験は,開発期間中に実施することが望ましい。
実施の手引
  新規の及び更新したシステムでは,一連の条件の下での試験活動,試験への入力及び予想される出力に
ついて,詳細な計画を作成することを含め,開発プロセスにおいて綿密な試験及び検証が必要となる。組
織内で開発するものについては,この試験は,最初に開発チームが実施することが望ましい。その次に,
システムが期待どおりに,かつ,期待した形でだけ動作することを確実にするために,組織内で開発する
もの及び外部委託したものの両方について,独立した受入れ試験を実施することが望ましい(14.1.1及び
14.2.9参照)。試験の程度は,そのシステムの重要性及び性質に見合ったものであることが望ましい。
14.2.9 システムの受入れ試験
管理策
  新しい情報システム,及びその改訂版・更新版のために,受入れ試験のプログラム及び関連する基準を
確立することが望ましい。
実施の手引
  システムの受入れ試験は,情報セキュリティ要求事項の試験(14.1.1及び14.1.2参照)及びセキュリテ
ィに配慮したシステム開発の慣行(14.2.1参照)の順守を含むことが望ましい。受け入れた構成部品及び
統合されたシステムに対しても,試験を実施することが望ましい。組織は,コード分析ツール又はぜい弱
性スキャナのような自動化ツールを利用することができるが,セキュリティに関連する欠陥を修正した場
合は,この修正を検証することが望ましい。
  試験は,システムが組織の環境にぜい弱性をもたらさないこと及び試験が信頼できるものであることを
確実にするために,現実に即した試験環境で実施することが望ましい。

14.3 試験データ

目的 試験に用いるデータの保護を確実にするため。
14.3.1 試験データの保護
管理策
  試験データは,注意深く選定し,保護し,管理することが望ましい。
実施の手引
  PII又はその他の秘密情報を含んだ運用データは,試験目的に用いないことが望ましい。PII又はその他
の秘密情報を試験目的で用いる場合には,取扱いに慎重を要する詳細な記述及び内容の全てを,消去又は
改変することによって保護することが望ましい(ISO/IEC 29101[26]参照)。
  運用データを試験目的で用いる場合は,その保護のために,次の事項を適用することが望ましい。

――――― [JIS Q 27002 pdf 65] ―――――

次のページ PDF 66