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

本記事の一部は Dark Reading に掲載されたものです。内容を更新し、転載しています。

‍

組織内の指揮命令系統を示す組織図は、キャリアの中で一度は目にしたことがあるはずです。組織図は、誰が誰の部下で、誰が上司なのかを明確にする便利なツールです。例えば、一般的な組織図では、開発グループのリーダーは製品開発ディレクターの直属となり、そのディレクターはイノベーション担当副社長の直属となります。このように、権限のラインは組織構造の上から下へと続いていきます。組織図の中で、自分の小さな枠がどこにあるのかを探した経験は誰にでもあるのではないでしょうか。

人間が階層や構造にこれほど魅了されるのも不思議ではありません。歴史的に見れば、それは古代の危険な世界で人類が生き残るために不可欠なものでした。人間は決して最強でも最速でもありませんでしたが、チームとしてうまく連携し、誰もが自分の役割を理解することで、家族や部族、集団を維持し、生き延びて繁栄することができました。現代の組織図は、まさにその時代の成功体験の延長線上にあるのです。

しかし、組織の規模やその他の要因にかかわらず、ほぼすべての組織図に共通することが一つあります。それは、図上の構成要素のほとんどが人間や人間のグループであるという点です。現時点では、機械が人間を管理する段階には至っていないため、組織図はあくまで人間だけのものとなっています。では、ソフトウェアにも組織階層が必要なのでしょうか。

もちろん、会社の組織図にソフトウェアを追加すべきだと言っているわけではありません。上司がアプリであってほしい人などいないでしょう。昇給の交渉をどうすればいいのでしょうか？しかし、現代のアプリケーションやプログラムが直面している脅威環境は、かつて人類の祖先が直面した危険な環境と似ています。アプリやソフトウェアの役割を厳格な階層構造の中で定義し、最小権限の原則に基づいてポリシーを適用することで、過酷な脅威環境下でも、それらを確実に存続させ、成長させることができるのです。

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

ソフトウェアにより良い組織階層が必要な理由を理解するには、まず脅威の現状を知る必要があります。今日の攻撃者や、彼らが利用するボットや自動化ツールは、防御のわずかな隙を常に狙っています。フィッシングなど人間を標的とした攻撃も続いていますが、熟練したハッカーの多くは、その活動の大部分をソフトウェアへの攻撃へとシフトさせています。

あらゆるソフトウェアが標的となる中、最も成功している攻撃はAPI（アプリケーション・プログラミング・インターフェース）を狙ったものです。APIは、開発者がアプリやプログラムの細かなタスクを実行するために使用する小さなソフトウェア部品です。多くの場合、柔軟でユニークな存在であり、開発プロセスの中で必要に応じてその場で作成されることもあります。

APIは確かに柔軟ですが、その機能に対して過剰な権限が付与されていることがよくあります。開発者は、管理対象のプログラムが開発・変更されても機能し続けるように、多くの権限を与えがちです。しかし、これは攻撃者に侵害された場合、特定のデータベースの一部にアクセスする以上の権限を奪われることを意味します。ネットワーク全体に対する管理者権限に近いアクセス権さえ奪われかねないのです。

現在、認証情報を盗む攻撃の大部分がAPIのようなソフトウェアに向けられているという調査結果は驚くべきことではありません。Akamaiは、その割合を全体の75%と推計しており、GartnerもAPIに関連する脆弱性が最も頻繁な攻撃ベクトルになっていると指摘しています。また、最新のSalt Labsのレポートでは、APIへの攻撃が前年比で約700%増加していることが示されています。

ソフトウェアのための組織図を作成する

組織が認証情報窃取の脅威に対抗する方法の一つに、ネットワーク内での最小権限の原則やゼロトラストの適用があります。これにより、ユーザーは業務やタスクを遂行するために必要最小限の権限しか与えられなくなります。このアクセス権は、時間や場所といった要因によってさらに制限されることもあります。こうすれば、たとえ認証情報が盗まれても、攻撃者が実行できる機能や時間は限られるため、被害を最小限に抑えることができます。

最小権限の原則は優れた防御策ですが、通常は人間のユーザーにのみ適用されます。私たちは、APIも高い権限を保持しており、多くの場合、人間ほど厳格に管理されていないことを忘れがちです。サイバー攻撃のパターンを追跡するOWASP（Open Web Application Security Project）が、不適切なアクセス制御を現在最大の脅威として挙げているのは、まさにこのためです。

この重大な問題の解決策は、ソフトウェアに最小権限の原則を適用することだと言うのは簡単ですが、実装は非常に困難です。まず、開発者に危険性を認識してもらう必要があります。その上で、今後はAPIやその他のソフトウェアを、コンピュータネットワーク内の組織図の一部として正式に配置するか、少なくともそのように想定する必要があります。例えば、あるAPIが予約アプリケーションの一部としてリアルタイムのフライトデータを取得する役割であれば、給与システムや財務システムに接続できる理由はどこにもありません。ソフトウェアの組織図上では、それらのシステムを結ぶ線は存在しないはずです。

組織内で稼働する数千、数百万ものAPIを網羅した組織図を開発者が作成するのは現実的ではないかもしれません。しかし、APIがもたらす危険性を認識し、業務に必要な権限のみに制限することは、現在蔓延している認証情報窃取攻撃を阻止する大きな力となります。まずは意識改革から始め、APIやソフトウェアを人間のユーザーと同じように厳格に扱うことが重要です。
‍

開発チームのレベルアップをお考えですか？当社のアジャイル学習プラットフォームと開発者向けセキュリティツールで、APIセキュリティの課題を解決しましょう。