LCNC-SEC-01: アカウントのなりすまし
リスク評価 *
3
2
3
3
要旨
ローコード/ノーコードアプリケーションには任意のアプリケーションユーザーが暗黙的に使用する開発者アカウントを埋め込むことができます。 これは権限昇格への直接的な経路を作り出し、攻撃者が他のユーザーの ID の後ろに隠れることを可能にし、従来のセキュリティコントロールを回避できてしまいます。
ビジネスユーザーへの説明
あらゆるシステムの重要なコンポーネントは、そのシステム内でユーザーがどのようなアクションを実行しているかを追跡することです。アカウントのなりすましが発生すると、あるユーザーが行ったアクションが別のユーザーによって行われているように「見えます」。
説明
ID は構築された各アプリケーション内に組み込まれ、複数のユーザーがそのアプリケーションを使用できます。 これによりアプリケーションユーザーが権限を昇格するための直接的な道筋を作り出してしまいます。これは一般的ではなく、可能な限り避けるべきです。
ローコード/ノーコードアプリケーションは独自のアプリケーション ID を持つのではなく、既存のユーザー ID を利用できます。 組み込まれた ID はアプリケーションの作成者に属するものであったり、データベース資格情報のようにチームで共有される共通の ID であったりします。 サービスアカウントや共有 ID であるかもしれません。
アプリケーションの ID がないため、ローコード/ノーコードプラットフォームの外部にある監視システムに機密データが露出することになります。 外部から見ると、アプリケーションを使用するユーザーはアプリケーションの作成者になりすますことになり、アプリケーションとその作成者を区別することはできません。 アプリケーションが異なる ID を使用してさまざまなプラットフォームで動作する場合、問題はさらに深刻になります。 そのようなケースでは、あるユーザーはファイル共有 SaaS にファイルを保存するために使用し、別のユーザーはオンプレミスのデータを取得するために使用することができます。
攻撃シナリオの例
シナリオ #1
ある開発者はデータベースからレコードを閲覧するためのシンプルなアプリケーションを作成しました。 開発者の ID を使用してデータベースにログインし、アプリケーション内に組み込まれた接続を作成します。 このアプリケーションでユーザーが実行するすべてのアクションは開発者の ID を使用してデータベースに問い合わせることになります。 悪意のあるユーザーはこれを利用し、このアプリケーションを使用して、アクセスしてはならないレコードを閲覧、修正、削除します。 データベースのログではすべての問い合わせが信頼できる開発者である一人のユーザーによって行われたことが示されています。
シナリオ #2
ある開発者は従業員が自分の個人情報をフォームに入力できるようにするビジネスアプリケーションを作成しました。 フォームの回答を保存するために、開発者は個人の電子メールアカウントを使用します。 ユーザーはこのアプリが開発者の個人アカウントにデータを保存していることを知る由もありません。
シナリオ #3
ある開発者はビジネスアプリケーションを作成して、それを管理者と共有しました。 その開発者は自分のユーザー ID を使用するようにアプリを設定します。 本来の目的から外れて、このアプリは開発者のユーザー ID を使用して、開発者の権限を昇格させることもできます。 管理者がアプリを使用すると、知らぬ間に開発者の権限を昇格してしまいます。
攻撃と悪用のシナリオの例 - ビジネスユーザー
シナリオ #1
ある開発者はデータベースに接続してレコードを更新するノーコード/ローコードのロボットプロセスオートメーション (RPA) アプリケーションを構築しました。その接続では管理者の認証 (ユーザー名とパスワード) を使用して更新を記録します。10 人の異なるユーザーがこの RPA プロセスを使用しますが、すべてのアクションは管理者によって行われたものとして記録されます。ログシステムは生産性を追跡したり、エラーを特定のユーザーに帰したり、悪意のある動作を特定したりできなくなります。
シナリオ #2
ある開発者は現場の営業チームを支援するアプリケーションを構築しました。開発者はアプリケーションを作成する際に認証情報 (ユーザー名とパスワード) を使用するため、アプリケーションを通じて行われたすべての売り上げは、販売を促進した営業担当者ではなく、開発者に帰属します。
防止方法
データベース/サービス/SaaS への接続をプロビジョニングする際、最小権限の原則を遵守する。
アプリケーションではユーザーアカウントではなく専用のサービスアカウントまたはアプリケーションアカウントを使用する。
アプリケーションでは接続ごとに異なる ID ではなく、すべての接続で一貫した単一の ID を使用する。 これらの接続には専用のサービスアカウントまたはアプリケーションアカウントを使用する。
これらの接続がアプリケーションを使用するユーザーによって共有されるか、ユーザーにその接続への直接アクセスを許可することによって共有されるかに関わらず、共有接続を通じて実行されるアクションの背後にいるアクターを特定するために、適切な監査証跡を維持する。
参考資料
Last updated