2025年までに合計 グローバルデータ作成 181 ゼタバイトに達します。 企業にとって、そのデータは資産であり、さまざまなテクノロジー プラットフォームを活用して、ロイヤルティを生み出し、新しいビジネスを引き付ける高度にパーソナライズされたカスタマー エクスペリエンスを作成することができます。 ただし、これらのエクスペリエンスは、共有セキュリティ モードを使用するクラウド インフラストラクチャに依存しています。 そこにリスクがあり、テクノロジーが成長してローコード プラットフォームとノーコード プラットフォームを使用するシチズン デベロッパーの新しい軍隊が組み込まれるにつれて、リスクは増大しています。
継承マインドセットの理解と克服
ガートナー は、2025 年までにエンタープライズ アプリケーションの 70% が、Salesforce や ServiceNow などのローコードおよびノーコード プラットフォームから構築されると推定しています。 継承ベースの考え方で対応することは、エンタープライズ アプリの XNUMX 分の XNUMX 以上を失敗に追い込む確実な方法です。
「継承の考え方」は、インフラストラクチャを悩ませている問題の適切な説明です。 それは、行われた仕事と彼らの前に来た人々に完全に依存している、金持ちで甘やかされて育った子供たちを思い起こさせます。 これはレガシーを構築する良い方法ではありません。また、システムを構築する方法としても同様に悪い方法です。
レガシーな考え方を持っている場合、インフラストラクチャは整っていると思い込んでしまいます。 プラットフォームは安全で、セキュリティが組み込まれています。管理者の前にテクノロジがあったという理由だけで、信頼が想定されます。
この継承の考え方は、ローコード プラットフォームとノーコード プラットフォームを悩ませています。 ユーザーは、プラットフォームの安全性に依存して、エンタープライズ インフラストラクチャ全体を通過します。 代わりに、そのプラットフォームのセキュリティはそのプラットフォームにのみ適用される必要があります。
たとえば、Salesforce 開発者が新しい見込み客のために自動割り当てプログラムを作成するとします。 彼らは Salesforce 内で社内の割り当てに使用していますが、問題ありません。 彼らはプラットフォームの安全性に頼ることができます。 彼らは、自動化を改善するためにそれを拡張することにしました。 そのプログラムを、ServiceNow、SAP、Oracle などの外部向け CRM に接続します。 継承の考え方が引き継がれます。Salesforce は安全です。 ServiceNow、SAP、またはサードパーティは安全です。
したがって、Salesforce + サードパーティ = 安全です。
しかし、そのプラス記号には多くの不明な点があります。 Salesforce で作成された内部プログラムを、サードパーティ プラットフォームで作成された外部プログラムに安全かつ準拠して接続するにはどうすればよいですか? その XNUMX つの文字には、エラーの余地がたくさんあります。
そして、それはたったXNUMXつの接続です。 Salesforce で作成された多くのプログラムは、何百もの他のプログラムに影響を与えます。 これは、開発経験がほとんどまたはまったくない人々によって、上記のプラス記号のように扱われる何百もの未知数です。
唯一の解決策は、DevSecOps の原則に戻って、その開発を現実に戻すことです。
DevSecOps フレームワークの確立
DevSecOps フレームワークは、概念が作成されて以来、書かれ、書き直され、再び書かれてきました。 それらを確立するときに車輪を再発明する必要はありません。 SAFECode とクラウド セキュリティ アライアンス XNUMX つの柱を構築しました。
- 連帯責任: セキュリティは企業内のすべての人の責任ですが、人々は自分が知らない基準を満たすことはできません。 サイバーセキュリティ ポリシーを推進し、それが企業全体に確実に普及するようにリードを割り当てる必要があります。
- コラボレーションと統合: 知識は共有され、伝達されなければなりません。 企業がレガシーの考え方に陥る理由の半分は、古いシステムを知っていた人がいなくなったことです。 継続的な知識共有は、この問題を解消するのに役立ちます。
- 実用的な実装: 実用的な実装は、開発者の経験に結びつきます。 困難でありふれた、扱いにくいプロセスは、長く続くことはありません。 セキュリティは開発プラクティスに組み込む必要があります。つまり、コードのすべての行にテスト行が必要です。 業績の良い企業は、ツールを使用してテスト コードの各行を自動化することで、それをさらに進めます。
- コンプライアンスと開発: コンプライアンス要件は、開発者がそれらから逸脱することを許可しない方法で開発プロセスをガイドする必要があります。 たとえば、金融機関の開発者は、グラム・リーチ・ブライリー法に準拠するように設計されたプラットフォームで作業します。 開発者は、プラットフォームに組み込まれているため、準拠するために行為の詳細を個別に知る必要はありません。
- オートメーション： 開発者の負担を軽減し、人的ミスのリスクを軽減するために、予測可能で反復可能な大量のタスクは可能な限り自動化する必要があります。
- モニター： 最新のクラウド インフラストラクチャは変化し、成長します。 それを追跡することは非常に重要です。理想的には、さまざまな相互接続すべてを一目で確認できる何らかの形式のオーケストレーションを使用することです。
で ローコードまたはノーコード これらの柱は、予想されるほど簡単ではありません。 これらのツールを使用する人々は、多くの場合、DevSecOps の基礎にほとんど精通していないビジネス エキスパートです。
人、プロセス、テクノロジーを結び付ける
ローコード プラットフォームとノーコード プラットフォームの使用は、実際にこのスキル ギャップを埋めるのに役立ちます。 従業員は新しいスキルを習得したいと考えています。 企業は、人、プロセス、テクノロジーに重点を置いた DevSecOps フレームワークを確立することで、これをサポートできます。
- プロセス： ゼロトラスト環境では、ローコードおよびノーコードの開発者は、システムの完全性を危険にさらすような接続を行うことを心配する必要はありません。 隔離されたシステムの外では、基本的な権限はありません。
- 人々： 説明責任の文化は、非難の文化とは異なります。 説明責任とは、個人ではなく問題に焦点が当てられているため、個人が問題や間違いを安心して報告できることを意味します。
- 検出技術： DevSecOps の原則を適切に実装する上で最大の障害となるのは、開発者の手に負えないテクノロジです。 彼らは、組織から与えられたものを使用しなければなりません。 その技術が機能しない場合、開発者は安全でも安全でもない回避策を考え出します。 本質的に、テクノロジーは XNUMX つの大きなシャドー IT ジェネレーターになります。
私たちは開発の刺激的な時代に生きています。 ソフトウェアを構築し、戦略をテストし、ビジネス価値を向上させる機会を持つ人がますます増えています。 しかし、それにはリスクが伴います。 そのリスクをテクノロジーにオフロードする方法を検討している企業は、探求の余地を残しつつ、開発を地に足の着いたものに保ちます。
