「技術的負債」を解消するにはどうすればいいでしょうか?効率的な DevOps チームのための 6 つの核兵器

[51CTO.com からのオリジナル記事] 現在、Netflix、Etsy、Flickr などの企業は、新機能をより短時間でより速くリリースし続けており、その成功の秘訣は「DevOps」の活用にあります。

[[230791]]

DevOps は現在、銀行、保険会社、政府、および多くの規制の厳しい業界組織で広く採用されています。

これは、継続的インテグレーション、継続的デリバリー、エンジニアリング チームと運用チーム間の障壁の除去に重点を置いたソフトウェア配信の新しい方法であり、リリースの高速化とリスクの低減を実現します。

DevOps はほとんどのソフトウェア チームによく知られていますが、実際にそれに相当するセキュリティ制御を実践し、維持しているチームはほとんどありません。

Uber や eBay など、大量の個人情報や機密情報を保管している組織は、DevOps を使用して開発と運用を合理化し、機能開発を加速することで、いくつかの重大な侵害を経験しましたが、セキュリティ リスクを二の次にしていました。

もちろん、情報セキュリティの高水準を維持しながら「迅速に前進する」ためにDevOpsを活用している企業も数多くあります。

上の図に示されている 6 つの基本原則をまとめました。

• コードとしてのセキュリティポリシー
• 職務の分離
• ワークフローとスピードに重点を置く
• 安全第一
• オートメーション
• テクノロジーの採用

[[230792]]

コードとしてのセキュリティポリシー

現在、DevOps のスピードとセキュリティをうまく組み合わせているチームの最も重要な特徴は、コードを使用してさまざまなセキュリティ ポリシーを指定していることです。

DevOps の基礎となるのは、「コードとしてのインフラストラクチャ」であり、「不変のインフラストラクチャ」とも呼ばれます。

オペレーターはコードを使用してインフラストラクチャの要件を宣言し、サーバーとソフトウェアを手動で管理および構成する古いモデルを置き換えます。

このアプローチにより、手動で構成されたサーバー「ユニコーン」の拡散を効果的に防ぐことができます。ユニコーンは、障害が発生したときに誰も再構築方法を知らないという厄介な状況につながる可能性があります。

さらに重要な点は、自動容量拡張もサポートし、新しく生成された機能をさまざまなテスト環境や本番環境に展開する方法を予測することです。

このインフラストラクチャを表すコードは、アプリケーション コードとともにソース管理にチェックインされ、バージョン管理、比較、保護が可能になります。

セキュリティ実践の経験が豊富な DevOps チームは、「コードとしてのインフラストラクチャ」モデルを採用することでアプリケーション セキュリティを管理できます。コードを使用して、新しいアプリケーションやマイクロサービスにおけるさまざまなセキュリティ ポリシー要件を宣言します。

たとえば、通貨換算サービスを提供するマイクロサービス用のセキュリティ ポリシーの次のスニペットは、Conjur ポリシー言語 (https://www.conjur.org/reference/policy.html を参照) で記述されています。

上記のように、その構文は人間が読めるもので、理解しやすいものです。つまり、このコードにより、通貨換算サービスがさまざまな通貨の値を格納するデータベース パスワードにアクセスできるようになります。

このポリシーは完全に独立しており、無限に繰り返すことができ、外部要因に依存せず、将来の解釈の対象にもなりません。ソース管理にチェックインし、アプリケーション コードの一部として内部的に実装できます。

毎日何千ものアプリケーション関連の権限を管理するセキュリティ担当者は、この「コードとしてのセキュリティ ポリシー」モデルを使用して、チームの能力を新たなレベルに引き上げ、作業をより予測可能にすることができます。これらはまさに、アプリケーション関連のセキュリティ権限を手動で構成する必要があったため、これまでは実現できなかったことです。

したがって、効率的で安全な DevOps プロセスを作成するには、「コードとしてのセキュリティ ポリシー」が不可欠です。これがなければ、後で説明するセキュア DevOps のさまざまな側面は​​実現できません。

[[230793]]

職務の分離

残念ながら、多くのソフトウェア チームでは、開発者と運用担当者が、サービス関連のアカウントの維持、さまざまなセキュリティ制御の定義、機密データへのアクセスの制御などのセキュリティ責任も負っています。これらは間違いなく、すでに「いっぱい」だった彼らの仕事量にさらに加わった。

職務の分離がスピードの原動力

職務の分離に関するほとんどの記事では、利益相反や詐欺の防止におけるその利点や、一人の人間が持つべき基本的な権限の量を減らすことができる点について言及しています。

しかし、別の観点から見ると、高パフォーマンスの DevOps チームは、職務の分離を、チーム メンバーが自分の得意分野にのみ集中できるようにし、各メンバーの能力に基づいてチーム全体のワークフローを適切に最適化する機会と見なしています。

成熟したチームには、役割が定義され、責任が明確に分担されています。セキュリティと監視は専任のセキュリティ担当者が担当し、開発者はコードの作成に集中し、運用担当者は実稼働環境のアーキテクチャが健全に動作することを保証します。

各機能グループ間のインターフェース「ハンドオフ」は、セキュリティ ポリシーに組み込まれます。つまり、開発者はアプリケーションやサービスに必要な権限を宣言するセキュリティ ポリシーを作成し、セキュリティ担当者は関連するコード変更を確認して承認し、運用担当者はアプリケーションがデプロイされ、期待どおりに実行できることを確認します。

責任の組み合わせ：痛みを伴うアンチパターン

開発、セキュリティ、運用のいずれかの役割を組み合わせると、組織は必然的に単一の役割に伴う重大なリスクにさらされることになります。

開発者は通常、本番システムで自分が持つ権限を認識していないため、自分の不注意が組織に与える損害の範囲を予見できません。

たとえば、昨年、ある会社のジュニアエンジニアが、出勤初日に誤って会社の生産データベースを削除してしまいました。これは、本番システム内のすべての権限が彼に与えられたために発生しました。

不幸な開発者は、アクセス権を持っていたため、気づかないうちに運用スタッフとしても活動していました。

したがって、問題の根源は彼ではなく彼の雇用主にあります。彼らは職務を分離せず、そもそもこのような状況が発生するのを防げなかったのです。

各役割の責任

開発者：

• 誤って本番環境に触れることを心配せずに、コードとテストケースを記述する機能。
• アプリケーションのホスト要件に関して運用スタッフとコミュニケーションをとります。
• アプリケーションのセキュリティ要件についてセキュリティ担当者とコミュニケーションをとります。

運営スタッフ:

• ホスト (仮想マシン) に対してアプリケーションの要件を実行して実装します。
• 実稼働環境の可用性を確保します。

セキュリティ担当者:

• アプリケーションのニーズに基づいて、開発者に関連する権限を付与します。
• システム内にさまざまなセキュリティ対策が実装され、適切に実施されていることを確認します。

企業が DevOps モデルを採用しても、開発者が運用の役割を担う必要がないのと同様に、「DevSecOps」を採用しても、開発者がセキュリティの専門家になる必要はありません。

したがって、高業績の組織は、「迅速に行動するが、ミスを頻繁に起こす」という行動状態を避けることを学ぶ必要があります。彼らが必要としているのは、誰もが自分の仕事を遂行し、間違いを犯さないことを知りながら迅速に前進できるモデルです。

[[230794]]

ワークフローとスピードに重点を置く

DevOps の中心的な概念は、持続可能でスムーズなワークフローを生み出すことです。

この目標を達成するために、DevOps チームは、さまざまな CI/CD パイプラインを作成し、継続的に小規模かつ頻繁なコード変更を行い、エンドツーエンドのデプロイメントを行い、マイクロサービス ベースのアーキテクチャに類似したシステム アーキテクチャを採用することで、上記の急速な進歩を達成する必要があります。

安全なワークフローをモデル化して最適化する

カンバンは、フローと開発速度に重点を置いた作業システムです。核となるのは、作業のさまざまな段階を視覚化することです。つまり、プロジェクトがさまざまな段階を経て進行するにつれて、各ステータスを視覚化することで、遅いステップを分解し、ボトルネックを特定し、速度を最適化するのに役立ちます。

リリースの遅延が慢性的に発生している組織では、システム内のセキュリティ レビュー フェーズに時間がかかることがあります。

その理由は通常、セキュリティレビューの開始が遅れ、大量の情報が関係するためです。言い換えれば、セキュリティ レビュー チームに一度に大量の負担が課せられているということです。

経験豊富な組織は、「安全を左側に置く」傾向があります (視覚的なカンバン ボードでは、ワークフローは左側から始まり、右側に流れるものと一般的に想定されています)。

つまり、セキュリティ チームが新しいバージョンや機能の開発に早く関与するほど、良い結果が得られます。同時に、開発サイクルの早い段階で重大なセキュリティ問題を明らかにすることができれば、プロセスの後半で配信の遅延を防ぐことができます。

スピード向上のためのマイクロサービスの強化

マイクロサービス アーキテクチャは、特にリリース速度を重視するセキュリティ チームに多くのメリットをもたらします。

先ほどの「通貨換算」マイクロサービスを例に挙げて説明を続けましょう。セキュリティ チームが単一のデータベースにアクセスするアプリケーションを確認して承認するだけでよい場合は、比較的簡単です。

しかし、機能が数百万行のコードを含む大規模なアプリケーションの一部である場合、セキュリティ チームは、レビューする必要がある重要な変更を見つけるために、多くの変更を精査する必要がある可能性があります。

同時に、大規模なアプリケーションのバージョンで大幅な変更が何度も行われている場合、レビューはより困難になります。

結局のところ、セキュリティ チームに数千行のコードをレビューさせるよりも、数十行のセキュリティ ポリシー コードをレビューさせる方がはるかに簡単です。

新しいバージョンで権限を変更する必要がない場合は、登録されたマイクロサービス コードの継続的なアップグレードを高速に保つことができます。

逆に、大規模なアプリケーションでマイクロサービスを廃止またはシャットダウンする必要がある場合は、関連するさまざまな結合関係とコード レベルの規模を考慮する必要があります。

ウォーターフォール開発を経験した従来のチームは、多くの場合、「ビッグバン」方式でアプリケーションをリリースする傾向があります。アプリケーションで品質上の問題が発生した場合、セキュリティ担当者をすぐに呼び出してコードレビューを実施する必要があります。

その結果、セキュリティ チームは、何千もの変更が蓄積されたアプリケーション コードや、できるだけ早くアプリケーションをリリースするというビジネス側からの絶え間ないプレッシャーに直面することがよくあります。

したがって、継続的な配信を維持する大規模なチームは、これを実現するためにコード ベースを複数のマイクロサービスに分割します。

同時に、セキュリティ チームにさまざまな専門的かつ洗練されたモデルを使用してさまざまなセキュリティ レビューを実施し、リリースの進行をスピードアップして可視性を向上させるよう依頼します。

プロセスを最初から最後まで簡素化

DevOps では、「エンドツーエンドの早期化」という概念が導入されています。これは、配送リスクを軽減し、見積りの信頼性を高める簡単な方法です。

チーム メンバーにとっては、新しいサービスに「パイプラインを接続」する速度が速いほど、展開プロセスをスムーズに構築し、頻繁なアップグレードや更新に対処する方法を早く習得できます。

同時に、一部の未完成の機能フラグを非公開で本番環境に展開し、新機能が完成した後に完全に表示してユーザーに公開することもできます。

このアプローチは、特にチームが「セキュリティ ポリシーをコードとして」という原則を採用している場合、サービスのセキュリティ変更のリスクを効果的に軽減することもできます。

たとえば、新しいサービスが社内の CRM データベースと支払いゲートウェイにアクセスする必要がある場合、チームの最初のタスクは、そのサービス用の CI/CD パイプラインを構築し、基本的な接続が構築されたらパイプラインをバージョン 0.1 にアップグレードすることです。

このようにして、サービスの権限は審査に合格し、展開が完了すると、本番環境のさまざまな機密リソースに「事前登録」された方法でアクセスできるようになります。

これにより、後続バージョンの展開リスクが排除され、開発者は残りの機能を後の段階で作成して実装できることがわかります。同時に、セキュリティ チームには、サービスの権限とセキュリティ構成の要件も事前に通知されました。

効率的な DevOps チームは、次の方法で高速かつスムーズなワークフローを実現できる必要があります。

• カンバン ビューを使用して、開発サイクルのボトルネックを発見し、最適化します。
• 「セキュリティを左側に置く」ことで、セキュリティ チームが開発サイクルにできるだけ早く参加できるようにし、関連するセキュリティ問題をできるだけ早く発見できるようにします。
• 「セキュリティ ポリシーをコードとして」アプローチを使用して、開発、セキュリティ、運用チーム間の効率的で明確なコミュニケーションを実現します。
• 大規模なアプリケーションを、それぞれ独自のセキュリティ戦略を持つ小さなマイクロサービスに分割します。
• セキュリティ チームがセキュリティ レビューを継続的に、小規模かつ予測可能な量で実施できるように、大規模な変更を最小限に抑えます。
• コンポーネントとモジュールの継続的なアップグレードに伴うリスクを軽減するために、できるだけ早く「エンドツーエンド」モデルを実装します。

会社に何百人もの開発者がいる場合でも、小規模なチームがある場合でも、上記の安全な開発プロセスの原則が役立ちます。

[[230795]]

安全第一

ソフトウェア チームは、重大なバグ、設計不良、システム パフォーマンスの低下に対して迅速に対応することがよくあります。なぜなら、これらの問題は明白かつ深刻だからです。

逆に言えば、彼らは予防的な作業を通じていわゆる「技術的負債」の解決を遅らせたり、将来それが制御不能になってより大きな問題を引き起こすまでそれを圧迫したりするだけです。

したがって、経験豊富な DevOps チームは、一般的にセキュリティの問題を「第一級の問題」として扱い、ToDo リストに入れたり、解決しないままにしたりするのではなく、緊急に解決する必要がある最初の場所に置く必要があります。

チームがアプリケーションの脆弱性とセキュリティに注意を払えば、開発およびリリースのプロセス中にさまざまな適切なセキュリティ対策が自然に講じられるようになります。これらのセキュリティ対策を詳しく見てみましょう。

安全なパスワード管理

パスワードのセキュリティ管理では、次の点に注意してください。

• 運用システムに関連するすべての暗号化情報 (パスワード、秘密鍵、または攻撃者に悪用される可能性のある機密情報) は、安全で可用性の高いリポジトリに保存し、アクセスを許可されたシステムのみが適切なタイミングでアクセスできるようにする必要があります。
• ライブラリ マネージャーは特定のパスワード値/情報にアクセスできません。
• パスワードの有効期間を制御するために、設定されたスケジュールに従ってパスワードが自動的に変更されるようにします。

安全に関する良い習慣

• 安全を重視するチームが頻繁に実践する安全に関するヒントをいくつか紹介します。
• 最小権限の原則はどこにでも適用できます。マシンと人は、アクセスに適したリソースにのみアクセスできます。不適切なアクセスが発生した場合は、対応する権限を直ちに取り消す必要があります。
• 関連するすべてのサードパーティ署名ライブラリに対して脆弱性スキャンが自動的に実行されます。最新のアップデートが利用可能な場合は、それぞれの脆弱性ライブラリを直ちにアップグレードする必要があります。
• 関連する脆弱性が検出されたかどうかに関係なく、サードパーティの署名ライブラリを最新の状態に保つ必要があります。一部のパッチは最新バージョンの署名ライブラリでのみ利用できる可能性があるため、アップグレードと更新を行うことで、大きな互換性の問題を回避できます。
• アプリケーション (およびその CI/CD 環境) は、潜在的な攻撃ベクトルに対して定期的に侵入テストを行う必要があります。これらのテストは、CD パイプラインの一部として自動化ツールによって実行される場合もあります。もちろん、ホワイトハットハッカーなどの定期的な人間の介入によっても効果を高めることができます。
• すべての新規開発者のトレーニング計画にアプリケーションおよび情報セキュリティのトレーニングを含め、継続的な教育を提供します。
• 攻撃ベクトルの考慮事項とセキュリティ ポリシー違反の正確なチェックと開示を含む、運用コードの変更のワークフローを開発します。たとえば、チームが GitHub PR (PullRequest) を使用する場合、送信者とレビュー担当者は両方とも同じ PR テンプレートを使用して記述する必要があります。

スタッフ全員が安全速度に努めています

一部の企業では、セキュリティ チームが障害になっているという評判がよくあります。現実には、セキュリティ チームが新しいシステムや取り組みについて知らされるのは、開発サイクルのかなり遅い段階であることが多いのです。

開発プロセスがどれだけスムーズかつ高速であっても、セキュリティ チームには常に、新しいテクノロジーの導入によってビジネス全体がリスクにさらされないようにする責任があります。

セキュリティ承認には時間がかかり、特に多数のプロジェクトが同時に実行されている場合は、当然、さまざまな不満が簡単に生じる可能性があります。

機能不全の組織では、開発者がセキュリティ チームの権限を覆すために未承認のアプリケーションを秘密裏に導入することで、事態がさら​​に悪化することもあります。

したがって、高業績を上げている組織は、上記の問題の根本的な原因、つまりセキュリティ チームが開発プロセスの間違った場所に配置されていることを認識する必要があります。

安全を左側に置く

経験豊富なチームは、新しいアプリケーションの開発の初期段階でセキュリティを直接考慮し、セキュリティ チームを関与させてアーキテクチャとテクノロジの選択を検討し、プロセスの中で「セキュリティを左側に配置する」ように努めることがよくあります。

これにより、セキュリティ チームは重大な問題を早期に特定し、大量のコードが記述される前に解決することができます。

同時に、この動きにより、開発者とセキュリティ担当者の間の議論が減り、調和のとれたチーム関係が形成されます。

一見すると、「安全を左に置く」というのは短期的には報われない選択のように思えるでしょう。しかし、開発ライフサイクル全体を見ると、早期にセキュリティ評価を行っておけば、後の段階でメインアーキテクチャに脆弱性が見つかった場合に、やり直しのコストを回避できることになります。

実際、早期のセキュリティレビューは開発プロジェクトのリスクを軽減するだけでなく、その後のリリース サイクルのコストも削減します。

[[230796]]

オートメーション

DevOps チームにとっては、QA、パッチ適用、デプロイメント、アップグレード、ロールバック、災害復旧を自動化でき、前述の「ミスのない迅速な前進」という効果が得られました。

優れたパフォーマンスを発揮する DevOps チームでは、過度のリスクを増大させることなく機能を迅速にリリースするために、既存の自動化計画にセキュリティも組み込む必要があります。

人間は自分が最も得意なことだけをする

経験豊富な DevOps チームは、システムの自動化を最大限に活用するだけでなく、人間が繰り返し実行することが多いタスクを自動化する機会を継続的に探しています。

そして、セキュリティは、この自動化された変革のカテゴリに分類されます。もちろん、安全な開発には人間にのみ適した側面もあります。

たとえば、新しいアプリケーションを起動する前や既存のアプリケーションを管理するときに、セキュリティ チームは権限を付与するための最適なオプションを確認して決定する必要があります。

侵入テストに利用できる効率的な自動ツールは数多くありますが、人間は常にソフトウェアやシステムを攻撃するためのより優れた新しい方法を見つけます。

自動化を促進し、人員を削減する

パフォーマンスの高い DevOps チームのほとんどでは、継続的インテグレーション (CI) パイプラインを設定して、アプリケーションを次のステージまたは運用環境に自動的にプッシュすると、運用担当者はアプリケーションのアップグレード後に関与する必要がなくなります。

同様に、アプリケーションのセキュリティ ポリシーが変更されておらず、新しい権限を追加する必要がない限り、セキュリティ担当者が承認プロセスに参加する必要はなく、ボトルネックが発生したり、アプリケーションの進行や起動に影響を与えたりすることはほとんどありません。

アプリケーションの登録は手動で承認されているため、アプリケーションの実行中にリソースにアクセスするための追加の権限が必要ない限り、アップグレードは完全に自動化されるはずです。

もちろん、セキュリティを損なうことなく自動アップグレードを実装するには、サードパーティのソフトウェア ライブラリのスキャンと CVE (Common Vulnerabilities and Exposures) の実行、アプリケーション コードにセキュリティ上の脆弱性があるかどうかの確認、侵入テストを実行するかどうかなど、CI パイプラインでさらに多くのタスクを設定する必要があります。

これらの自動構成には多少の時間がかかりますが、それらが蓄積されると、コスト、リスク、および全体的な所要時間は手作業よりもはるかに少なくなります。

自動化されたセキュリティ

データセンターの自己修復機能と災害復旧 (DR) テクノロジの発展に伴い、自動化されたセキュリティは、次の発展経路に沿って、運用中に発生する可能性のあるさまざまな複雑な障害を徐々に軽減してきました。

手動で有効にする必要があるバックアップ サイトを維持します。

手動サイト切り替えプロセスに関する定期的な訓練とテストを実施します。

別のサイトへの切り替えは完全に自動化されています。

複数のサイトまたはリージョンが同時に実行され、障害が発生した場合でも、システム内のすべての差異が自動的に同期されます。

テストは、カオス エンジニアリングの原則を使用してインフラストラクチャ障害を意図的に発生させることによって行われます。

自動侵入防止

自動化は、効率的なセキュリティ チームがタイムリーに障害に対応するのを支援するだけでなく、さまざまな侵入行為の発生を防ぐこともできます。

周知のとおり、攻撃者がシステムに侵入するには時間がかかります。重要なデータベース アカウントのパスワードを 90 日ごとに手動で変更する必要がある場合、攻撃者はパスワードを解読するのに数か月かかります。

ただし、そのデータベースのパスワードが毎日（ポーリング方式で）自動的に変更されるか、またはより頻繁に変更される場合、パスワードを解読する能力は大幅に低下します。

自動侵入対応

侵入を防ぐためのもう 1 つの重要な要素は、インフラストラクチャを定期的かつ自動的にリファクタリングすることです。つまり、仮想マシン テクノロジーと自動化されたプロセスにより、ダウンタイムなしでサーバーを既知の良好な状態に迅速かつ定期的に復元できます。

多くの組織では、侵害が検出されると、さまざまな自動応答プロセスによって自動回復プロセスが開始され、すべてのパスワードがポーリングされ、関連するすべての「呼び出し可能な」コンポーネント (仮想マシン、コンテナーなど) が既知の良好な状態に再作成されます。

災害復旧計画は継続的にリハーサルする必要があることを上で述べたように、自動化されたプロセスも継続的にテストおよび実行できれば、関連するリスクは大幅に軽減されます。

[[230797]]

テクノロジーの採用

テクノロジーは急速に進化しているため、セキュリティ専門家は開発者から、時代遅れのポリシーを強制する人、最新のツールの採用を拒否する人としてレッテルを貼られることがよくあります。

現在、DevOps ではさまざまな SaaS 製品が使用され、CI、CD、構成管理、さまざまなオーケストレーションのためのさまざまなオープンソース ソリューションがサポートされています。

セキュリティ チームがこの環境に適応し、業務を円滑に遂行するには、これらの新しいシステムとテクノロジを採用する必要があります。

安全概念の変化

能力の低いセキュリティ チームは、新しいテクノロジーを否定的に捉えます。彼らにとって、現代のツールは、ますます増大する脅威ベクトル、潜在的な脆弱性、そして攻撃への露出を意味します。

優れたセキュリティ チームは、新しいツールを安全に導入できれば、組織のビジネスがより高速化されるだけでなく、組織のセキュリティも強化されると楽観視しています。

従来の IT セキュリティの概念は、静的なローカル データ センターと既知の資産インベントリに基づいています。システム境界では、境界ファイアウォールがさまざまな攻撃に抵抗するための主な防御手段として機能します。

一方、内部セキュリティ システムは、組織内の人とマシンの管理に重点を置いています。 LDAP、Kerberos、および Active Directory は、ID とロールを管理するための主流のツールです。新しく追加されたマシンや新しく雇用された従業員は、システムに手動で構成する必要があります。

今日、現代の組織は、マイクロサービス、コンテナ、オーケストレーター、サーバーレス テクノロジーを使用して動的なインフラストラクチャを管理しています。

明らかに、これらは従来のセキュリティ概念と一致していません。新しいセキュリティ コンセプトは、生産環境における資産の「保護」ではなく、企業の急速な進歩をより良く「安全にサポート」することに重点を置いています。

新しい技術が安全性を向上

新しいセキュリティ保護対策により、さまざまなセキュリティ プロセスが IT システムの発展に追いつき、シャドー IT の脅威を防ぐことができます。

たとえば、Beyond Corp は、さまざまな社内アプリケーションを一般的な展開モデルに変換する Google のセキュリティ モデルです。 Google は、これらの機密性の高いアプリケーションを VPN の背後に配置する代わりに、パブリック インターネット上に展開しました。

これらのアプリケーションへのアクセスは、訪問者が接続しているネットワークではなく、訪問者の ID に完全に依存します。これにより、従来の IT 戦略が破壊され、Google やそれを利用する他の組織に驚異的なスピードと柔軟性がもたらされます。

Conjur も、自社製品内のすべての動的コンピューティング資産とユーザーに ID 認識を適用するという同じセキュリティ コンセプトを採用しています。

その他の開発者中心のテクノロジーも、開発者がアクセスする必要のある機密資産の数を大幅に削減します。職務の分離をより適切に実現するのに役立ちます。

たとえば、Pivo​​tal Cloud Foundry などの PaaS システムや Kubernetes などのデプロイメント オーケストレーターは、運用から完全に分離され独立したシステムの明確なビューを開発者に提供します。

サーバーレス テクノロジーはシステムのセキュリティを大幅に向上させることもできます。仮想マシンやコンテナを使用する開発者はオペレーティング システムに「近いアクセス」を持つため、資産や機密データにリスクが生じます。

ただし、サーバーレスまたは「Function as a Service (FaaS)」モデルでは、これらの資産にはまったくアクセスできません。

したがって、ほとんどのセキュリティ チームにとっては、開発者がアクセスする可能性のある資産を監視して保護するよりも、開発者に「知らせない」方がよいでしょう。

古い考え方と新しいアイデア

従来の IT セキュリティ モデルは、どの資産を制御する必要があるかを決定し、それらを「保護」するための構造を構築することに重点を置いています。したがって、すべてのワークフローはこの集中管理および制御モデルに基づいています。

新しいアプローチでは、システム資産マッピングチャートの完全なセットが利用できなくなり、シンプルだが効果的なガイドラインを使用する必要があると想定しています。

つまり、各エンティティに ID を持たせ、権限の変更をポリシーを通じて明確に伝達し、責任の分離を明確にし、自動化を通じてビジネスの推進速度を向上させる必要があります。

この新しいコンセプトにより、現代の DevOps チームはセキュリティを犠牲にすることなく、高い配信速度を維持できるようになります。そして、この新しい概念、方法、モデルは、すべての組織に受け入れられるはずです。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]