組織階層におけるソフトウェアの再考

この記事のバージョンが掲載されました ダークリーディング。ここで更新され、シンジケートされました。

‍

誰もがキャリアのどこかの時点で、組織の誰が誰に部下するかを定義する業務報告または階層図の1つを見たことがあるでしょう。単に「an」と呼ばれることもあります。 組織図これは、誰が自分のために働いているのか、上司は誰なのかを人々に知らせる便利なツールです。たとえば、一般的な組織図では、コーディンググループの責任者が製品開発部長に直属し、その部長がイノベーション担当副社長の直属になる場合があります。そして、権限の境界線は会社構造の上下を繰り返します。これらのチャートを見て、どこかに隠れている自分だけの小さなブロックを見つけようとしたことがない人はいますか？

人間がヒエラルキーと構造にこれほど魅了されるのも不思議ではありません。それこそが、私たちが非常に危険な世界に直面していた古代にまでさかのぼっても、歴史的に私たちを種として長い間生き続けてきた理由です。私たちは決して最強でも最速の生き物でもありませんでしたが、家族、部族、またはグループをまとめて生き生きと繁栄させるための自分の位置と責任を全員が知っていたので、チームでうまく協力して働きました。現代の組織図は、実際にはその時代と古代の成功の延長線上にあります。

しかし、事業規模やその他の要因に関係なく、ほぼすべての組織図に共通することが1つあります。ほとんどの場合、これらの組織図のすべての構成要素は、人間または人間のグループを表しています。まだ機械が人間を監視できる段階には達していないので、今のところ、組織図はもっぱら人間だけのものです。しかし、私たちのソフトウェアには組織階層も必要でしょうか？

もちろん、会社の組織図にソフトウェアを追加することを提案しているわけではありません。誰も上司向けのアプリを持ちたいとは思っていません。どうやって彼らに昇給を頼むの？しかし、私たちのアプリケーションやプログラムが最近直面している脅威の状況は、太古の人類がずっと前に直面していた危険な環境と変わりません。アプリとソフトウェアの責任を厳密な階層の中で定義し、それらのポリシーを最小限の権限で適用できるようにすることで、非常に厳しい脅威環境が立ちはだかっているにもかかわらず、アプリやソフトウェアも存続し、繁栄できるようにすることができます。

アプリとソフトウェアへの攻撃が過去最高を記録

ソフトウェアのより良い組織階層を構築する必要性を理解するには、まず脅威の状況を理解することが重要です。最近の攻撃者や、そのために機能するボットや自動化主導のソフトウェアは、悪用すべき防御策の欠陥を絶えず探しています。フィッシングやその他の人間に対する攻撃はまだ行われていますが、最も熟練したハッカーは、その取り組みの大部分をソフトウェアの攻撃に振り向けています。

すべてのソフトウェアが標的にされていますが、最も成功した攻撃はアプリケーションプログラミングインターフェイス（API）に対して行われています。これらの控えめな API は、開発者がアプリやプログラムのさまざまな小さいながらも重要なタスクを実行するために使用する小さなソフトウェアです。多くの場合、柔軟で独自性があり、開発プロセスの必要に応じてその場で作成されることもあります。

API は確かに柔軟ですが、多くの場合 かなり権限過剰 その機能のために。開発者は、たとえば、管理するプログラムの開発や変更が続けられても機能し続けることができるように、多くの権限を付与する傾向があります。つまり、攻撃者がセキュリティを侵害した場合、特定のデータベースの 1 つの部分へのアクセス権など、それ以上のものが与えられることになります。さらに、ネットワーク全体の管理者権限に近い権限を奪う可能性もあります。

いくつかのセキュリティ調査会社が、今日の認証情報を盗む攻撃の圧倒的多数がAPIなどのソフトウェアに対して行われていると言っているのも不思議ではありません。アカマイはその数字を次のように計算しています。 全体の 75%、ガートナーもそう言っていますが API に関連する脆弱性 最も頻繁な攻撃ベクトルになっています。Salt Labs の最新レポートでは、API に対する攻撃が報告されています。 ほぼ 700% 上昇 去年と比べて。

ソフトウェアの組織図の作成

組織が認証情報を盗む脅威に対抗する方法の 1 つは、ネットワーク内で最小限の権限またはゼロトラストを強制することです。これにより、ユーザーは自分の仕事やタスクを遂行するのにかろうじて必要な権限しか与えられません。そのアクセスは、時間や場所などの要因によってさらに制限されることがよくあります。そうすれば、認証情報を盗む攻撃が成功しても、攻撃者は限られた機能を実行する権限が短時間しか与えられないため、攻撃者にはあまり役に立ちません。

最小権限は有効な防御策ですが、通常は人間のユーザーにのみ適用されます。API にも昇格された権限があり、規制がそれほど厳しくないことが多いことを忘れがちです。これが理由の 1 つです。 壊れたアクセス制御 サイバー攻撃パターンを追跡するオープンウェブアプリケーションセキュリティプロジェクト（OWASP）によると、今や最大の敵です。

この重大な問題の解決策は、ソフトウェアに最低限の権限しか適用しないことだと言っても過言ではありません。しかし、実装するのはずっと難しいです。まず、開発者に危険性を認識させる必要があります。そして今後、API やその他のソフトウェアは、それが置かれるコンピュータネットワーク内の組織図の一部として公式に配置されるか、少なくとも想定されるべきです。たとえば、API が予約アプリケーションの一部としてリアルタイムのフライトデータを取得することになっているのであれば、給与計算システムや財務システムとも連携できるようにすべき理由はありません。ソフトウェアの組織図には、これらのシステムを直接結ぶ線も点線もありません。

開発者が組織内で稼働している数千または数百万の API を示す組織図を実際に作成するのは、おそらく非現実的です。しかし、彼らがもたらす危険性を認識し、その権限を自分の仕事に必要なものだけに制限することは、最近誰もが直面している横行する認証情報を盗む攻撃を阻止するのに大いに役立ちます。まず認識することから始めて、API とソフトウェアを人間のユーザーと同じように精査して扱うことで終わります。
‍

開発チームを昇格させたいですか？API のセキュリティ問題などを弊社で解決してください アジャイル学習プラットフォーム そして開発者ファーストのセキュリティツール。