ソフトウェア開発　ライフサイクル・ポリシー – AI AVATAR ヘルプセンター

目的

このポリシーは、情報セキュリティプログラムに準拠した AI AVATAR ソフトウェアシステムの承認、計画、ライフサイクル開発をサポートするためのガイダンスを、ビジネスプログラムマネージャー、ビジネスプロジェクトマネージャー、テクニカルプロジェクトマネージャー、およびその他のプログラムおよびプロジェクトの関係者に提供するための高レベルの要件を定義します。

役割と責任

代理 CTO および/または情報セキュリティ責任者は、このポリシーを促進および維持し、すべての従業員がポリシーを確認して読んだことを確認します。

ポリシー

AI AVATARは、コンピュータ・アプリケーションまたはシステムが、一貫性があり反復可能なSDLCプロセスに従い、すべての段階で情報セキュリティを維持することを保証するためのプロセスを確立し、維持する必要があります。

ソフトウェア開発フェーズとアプローチ標準

ソフトウェア開発プロジェクトは、定義された一連のフェーズで構成されます：

システムニーズ特定フェーズ
システムニーズ特定フェーズは、情報システムのニーズを特定し、そのニーズに対応するために必要なリソースを投入するかどうかを決定する期間です。

システム要件定義フェーズ
システム要件定義フェーズは、ユーザー要件を、設計およびコーディング時に使用できる詳細な要件に細分化する期間です。適用可能なセキュリティ要件と管理策は、情報セキュリティリスク評価を通じて特定されます。

システムコンポーネント設計フェーズ
システムコンポーネント設計フェーズでは、要件を仕様に変換し、開発フェーズの作業の指針とします。このフェーズで行われる決定は、システムが機能要件、物理要件、インターフェース要件、データ要件、およびセキュリティ要件をどのように満たすかを検討します。設計フェーズの活動は反復的に実施され、システムの機能的特徴と技術的詳細を重視したシステム設計が作成されます。

システムコンポーネント構築フェーズ
システムコンポーネント構築フェーズでは、詳細なシステム設計が完全なコード化されたソフトウェアユニットに変換され、最終的にはリリース用の統合製品へと仕上げられます。各ソフトウェアユニットとそれに続く統合ユニットは、セキュリティ脆弱性のテストを含め、徹底的にテストされます。インストールと運用をサポートするシステムドキュメントもこのフェーズで作成されます。

システム準備状況評価フェーズ
システム準備状況評価フェーズでは、設計・構築されたシステムが、ユーザー要件と適用されるセキュリティ要件を満たしていることを確認します。可能な限り、独立したテスターが、顧客が要求する機能を実行するシステムの能力を測定し、許容可能なレベルの品質、パフォーマンス、セキュリティを確保します。このフェーズが完了すると、システムが運用または再開発の準備ができているかどうかが明確になります。

システム導入フェーズ
システム導入フェーズは、開発ライフサイクルの最終フェーズです。このフェーズでは、システムは最初にパイロットサイトにリリースされ、そこでさらなるセキュリティ上の脆弱性が特定されます。その後、本番環境に導入されます。システムの使用に必要なすべてのトレーニングが実施されます。

プロジェクト管理
開発フェーズの順序は、採用するソフトウェア開発アプローチによって異なります。プロジェクト管理アプローチには、以下のものが含まれますが、これらに限定されるものではありません：

ウォーターフォール開発
アジャイル開発
反復型開発
段階的デリバリー開発

ソフトウェア開発のアプローチと規模に応じて、一部のフェーズを組み合わせることができます。反復型開発では、最終的なソフトウェアがリリースされるまでに、上記のフェーズを複数サイクル（反復）繰り返す場合があります。

SDLCセキュリティ管理ガイドライン

SDLCプロセスは、以下の情報セキュリティ管理に準拠します。

ソースドキュメントの作成と承認における職務分離を確保するための適切な手順を確立する必要があります。これには、開発/テスト環境に割り当てられた担当者と本番環境に割り当てられた担当者間の職務分離が含まれますが、これに限定されません。
コードの変更または緊急リリースは、変更管理標準に従います。
セキュアプログラミング標準に従う必要があります。AI AVATARの開発者には、セキュアコードに関するトレーニングを提供する必要があります。
安全な開発環境は、以下の基準に基づいて構築されます。
- システムによって処理、保存、送信されるデータの機密性
- 適用される外部および内部要件（例：規制やポリシー）
- 組織が既に実装している、システム開発をサポートするセキュリティ管理
- 環境で作業する人員の信頼性
- システム開発に関連するアウトソーシングの程度
- 異なる開発環境間の分離の必要性
- 開発環境へのアクセス制御
- 開発環境およびそこに保存されるコードへの変更の監視
- 安全なオフサイトの場所へのバックアップの保管
- 環境間のデータの移動に対する制御
企業またはホスト型インフラストラクチャに導入されるすべてのソフトウェアは、SAN や OWASP でカバーされているものを含む、セキュリティ上の問題を防止する必要があります。
コード変更は、元のコード作成者以外の担当者、およびコードレビュー技術とセキュアコーディングプラクティスに精通した担当者によってレビューされます。
編集チェック、承認、および確認済みトランザクションの変更のオーバーライドは、適切に承認、文書化、およびレビューされる必要があります。
アプリケーション開発活動は、本番環境およびテスト環境から分離する必要があります。論理的または物理的な分離の範囲は、ビジネスアプリケーションのリスクに適切であるか、顧客の契約要件に準拠していることが推奨されます。本番環境、開発環境、テスト環境間で必要な分離レベルを評価し、その分離を確保するための管理策を確立する必要があります。
本番環境へのすべての変更は、変更管理手順に厳密に従う必要があります。これには、すべての変更に対する当該環境の権限のある所有者による人的承認が含まれます。承認なしの自動更新は禁止する必要があります。
稼働中の本番環境はテスト環境として再利用してはなりません。非アクティブまたは廃止された本番環境は、すべての個人データが削除されていない限り、テスト環境として使用してはなりません。テスト環境は、テストデータ、ツールなどの残留物をすべて削除する廃止および再導入プロセスを経ない限り、本番環境として再利用してはなりません。
インターネットに面したアプリケーション、またはウェブ技術を利用し顧客情報を扱う内部アプリケーションのサポートまたはコード作成に責任を持つ個人は、安全なコーディングの実践に特化したセキュリティトレーニングを毎年受ける必要があります。インターネットに面したアプリケーションのコードをサポートまたは記述する個人については、インターネットの脅威に関するトピックもトレーニングに含める必要があります。個人は、コードを書いたりサポートしたりする前に、トレーニングを完了する必要があります。このトレーニングには、OWASP のセキュア開発原則と、OWASP のトップ 10 脆弱性アウェアネスが含まれていなければなりません。
アプリケーションがアクティブになる前、または顧客にリリースされる前に、カスタムアカウント、ユーザーID、パスワードをアプリケーションから削除する必要があります。
本番環境のデータは、テスト環境や開発環境で使用してはなりません。
テストシステムにおける本番環境コピー用のセキュリティ管理策は、本番環境品質に準拠する必要があります。（例：本番環境管理策をデータにミラーリングする）
ユーザー入力を必要とする新機能のリリース前に品質保証（QA）テストを実施し、ユーザー入力の制約が合理的に理解できる場合は、機能受け入れテストにエッジケースと境界ケースのテストを含める必要があります。

テストで本番環境のデータを使用する必要があることを示す状況の場合、要件は次のとおりです：

情報リソース所有者は、本番環境データをテスト目的で使用する前に承認を与える必要があります。
可能な限り、本番環境データは本番環境データを使用する代わりに、トークン化または匿名化する必要があります。
テストおよび並行実行では、本番環境データの別のコピーを使用し、テスト場所または送信先は適切な場所である必要があります。（例：機密性の高い本番環境データをテストのためにラップトップにロードすることは許可されません）
データは、テストプロセスにおいて、不正な開示につながるような方法で抽出、処理、または使用されるべきではありません。
データへのアクセスは、必要最小限のユーザーに限定される必要があります。
通常のテスト活動では、本番データを使用すべきではありません。テスト活動で本番データへのアクセスが必要な場合、本番データへのアクセスは、文書化された業務上の必要性がある個人のみに制限されるべきです。これらのユーザーは、文書化された業務上の必要性がある情報のみにアクセスできるようにする必要があります。
テストに使用された本番環境データは、テスト完了後、安全に消去する必要があります。
テストデータとアカウントは、本番環境に移行する前に削除されます。
制限/保護対象情報は、保存中および転送中は暗号化標準に従って暗号化されます。
エラーメッセージは安全に処理する必要があり、機密情報を漏洩してはなりません。

変更管理

運用システムへのソフトウェアのインストールと変更

オペレーティングシステムのアプリケーションとソフトウェアは、徹底的なテストをパスした後にのみ実装されます。テストは以下の内容を含みます：
- ユーザビリティ
- セキュリティ
- 他のシステムへの影響
- ユーザーフレンドリー
- テストは別のシステム（テスト環境）で実施され、対応するすべてのプログラムソースライブラリも適宜更新されます。
AI AVATARの業務用ソフトウェア、アプリケーション、プログラムライブラリは、適切な管理者の承認に基づき、訓練を受けた管理者によってのみ更新されます。
会社の運用システムは、承認された実行可能コードのみを保持し、開発コードやコンパイラは保持しません。
構成制御システムは、実装されたすべてのソフトウェアとシステムドキュメントを制御するために使用されます。
- 以前のバージョンのソフトウェアは、緊急時対応策として保持されます。
- 古いバージョンのソフトウェアは、必要なすべての情報とパラメータ、手順、構成の詳細、およびサポートソフトウェアとともに、データがアーカイブに保持されている限りアーカイブされます。
変更が実施される前に、ロールバック戦略が策定されます。
運用プログラムライブラリへのすべての更新の監査ログが保持されます。
新しいバージョンリリースへのアップグレードを決定する際には、次の点を考慮する必要があります。
- 変更に関するビジネス要件
- リリースのセキュリティ（例：新しい情報セキュリティ機能の導入、またはこのバージョンに影響を与える情報セキュリティ問題の数と重大度）。

変更管理手順

合意された承認レベルの記録は保持されます。
変更は承認されたユーザーのみが提出できます。
変更によってコントロールや整合性手続きが侵害されないことを確認するため、レビューが行われます。
修正が必要なすべてのソフトウェア、情報、データベースエンティティ、ハードウェアが特定されます。
既知のセキュリティ脆弱性の可能性を最小限に抑えるため、セキュリティ上重要なコードが特定され、チェックされます。
詳細な提案については、作業開始前に正式な承認を得なければなりません。
権限を与えられたユーザーは、実施前に変更を受け入れなければなりません。
変更は、関係するビジネスプロセスへの影響が最も少ない時期に実施されます。
ベンダー提供のソフトウェアは、変更せずに使用されます。
変更が必要な場合は、次の点が評価されます：
- 組み込みのコントロールと整合性プロセスが損なわれるリスク
- ベンダーの同意
- ベンダーからの変更を標準アップデートとして取得する
- プログラムの保守責任を負うことの影響
- 使用中の他のソフトウェアとの互換性
オペレーティングプラットフォーム（オペレーティングシステム、データベース、ミドルウェアプラットフォーム）の変更後、アプリケーションの技術レビューを実施します。レビューの内容は以下のとおりです。
- アプリケーション制御および整合性手順を整備し、運用プラットフォームの変更による影響が及ばないようにします。
- 運用プラットフォームの変更は適時に通知し、実装前に適切なテストとレビューを実施します。
- 事業継続計画に適切な変更を加えます。

関連記事