職務の分離は要件ですか？
私たちの環境で。開発者は、開発、テスト、および本番環境で完全な権限と特権を持っています。これにより、金融取引に関連するコードを作成、操作、および昇格させることができます。私たちのセキュリティ部門にとって、これは分離/職務分離の問題を表しています。しかし、開発者たちは同意しません。それを必要とするものは何もないと彼らは言います。弊社のポリシーを記載する以外に、参考にできるものはありますか？
O'Reillyの本として、第2章のDevOpsSecの詳細は、職務分離（SoD）が情報セキュリティ標準の主要なコンポーネントです：ISO 27001、NIST SP 800-53、COBIT、 ITILなど-および（最低限）の規制要件の一部：FFIEC、サーベンスオクスリーセクション404、SSAE 16、GLBA、MiFID II、およびPCI DSS。
開発者は、不変インフラストラクチャなどの読み取り専用環境（つまり、「SSHを使用しない動作」）がベストプラクティスであることに同意します。 Martin Fowlerなどの開発者ヒーローが、完全な ImmutableServer モデルではない場合でも、PhoenixServerの概念を直接規定していることもわかります。
ただし、3つの防衛線（3LoD）が組み込まれている組織（たとえば、金融サービス会社や、内部および/または外部の監査機能がある場所）では、読み取り専用機能でさえ要件を満たすのに十分ではない場合があります（監査に合格します）。
DevOpsSecブックでは、不変インフラストラクチャとSoD（これも推奨）に加えて、次の推奨事項が記載されています。
- 非公開のデータと設定へのアクセスを制限します。
- ログに機密データが含まれていないことを確認するには、ログコードを注意深く確認してください。
- 開発者が本番で行うすべてのことを監査および確認します。つまり、実行するすべてのコマンド、見たすべてのデータです。
- 継続的デリバリーパイプラインの外部で行われたコードまたは構成への変更を追跡するために、検出変更管理を導入する必要があります。
- また、データの引き出しについても心配する必要があります。つまり、開発者がシステムからデータを取り出せないようにする必要があります。
もう1つの報酬管理は、Rotation of Duty（RoD）です。これは、SoDとよく併用されます。頻繁に人を回転させ、共謀の状況を回避する場合、これは他の強力なコントロールを補い、バックアップすることができます。最後のピースは、完全なチェックアンドバランスシステムが「No Dark Corners」パラダイムを介して信頼できる内部関係者を防ぐ機能を含む2者間の完全性です。
また、DevOpsとアプリケーションセキュリティの業界エキスパートであるBen Tomhaveの新鮮な視点もいくつか紹介します http://www.newcontext.com/devops-and-separation-of-duties/
情報セキュリティの専門家として、私はあなたのITセキュリティ部門の評価に同意します。セキュリティのベストプラクティスに従うには、多くの場合、個人がそのようなプラクティスの背後にある意図を理解する必要があります。この場合、職務の適切な分離、SoD
あなたの会社の開発者は十分に動機付けられていないようで、SoDの利点を理解していないので、SoDを遵守することでどのように利益が得られるかを説明します。このインスタンスでOPに何が起こったかを見てみましょう。合理的な開発者は、本番環境にアクセスできないかどうかを理解し、認証と説明責任のセキュリティAAAの他の2つの要素が機能していると想定すると、開発が完了した後にコードから問題が発生しても非難できません。
開発者は、CIAの原則に違反することにより、責任を負い、悪意を持って本番環境の財務データやクレジットカード情報に損害を与えることはありませんが、他の開発者は責任を負わない場合があります。生産中の機密の財務データでインシデントが発生した場合、会社に大きな罰金が科される可能性があり、評判が損なわれると、会社の規模に基づいてfuture収益が失われる可能性があります。ビジネスの存続に疑問を投げかける開発者のキャリア/生活に直接影響を与える
最後に、@ atdreが提供する優れた回答のポイントを拡張して、修正的なインシデント対応コントロールを使用して、検出的変更管理コントロールを補完する必要があります。監視プログラム（TripWireなど）から本番データに加えられた不正な変更を検出した場合、行われた損傷から回復するための補正制御（テスト済みのバックアップからの復元の利用など）を実施する必要があります。