先月私は書いた 記事 ローコード/ノーコードプラットフォームがサービスとしてクレデンシャル共有を提供する方法、それらがそれを行う理由、およびこれがどのように見えるかについて 攻撃者の視点。 この記事では、その妥協の影響と、それが今日の企業にどのように影響するかに焦点を当てます。
これが、企業の資格情報を他の誰かと共有することが悪い習慣である理由です。 XNUMX回限りのユーザー行動分析のために本番ログを照会するために、自分の資格情報を同僚に渡したいとします。 一般的な企業では、新しいデータソースをクエリする権限を誰かに付与することは、特に本番データや機密データに関しては、長いアクセスレビュープロセスを意味する可能性があります。 私の同僚は簡単にイライラする可能性があります。 「私が望んでいたのは、この小さなXNUMX回限りのクエリを実行することだけで、すでにXNUMXか月待っていました！」 彼らは言うことができます。 それらのクエリを実行することもできますが、私は自分の日常のタスクに圧倒され、XNUMX回限りのクエリは複雑になる傾向があります。
簡単な解決策がXNUMXつ残っています。それは、ユーザー名/パスワードを同僚と共有することだけです。 彼らがMFAチャレンジを取得した場合、私は喜んで承認します。 クエリの実行に時間を費やす必要はなく、同僚のブロックが解除されます。 誰もが勝ちます！ 右？
さて、あなたはあなたの分析に正しいでしょう、しかしあなたは全体像を見逃しています。 同僚がユーザーの行動分析を行うことは企業にとって重要ですが、企業がプライバシーとセキュリティの標準のホスト全体に準拠し続け、セキュリティに対する企業の取り組みを維持することによって顧客の信頼を維持することも同様に重要です。 。
高レベルの企業目標で納得がいかない場合は、ITまたはセキュリティの中央管理チームを検討してください。 これらのチームは、各ユーザーが独自のIDを持っているという事実に基づいて運用とセキュリティ戦略を立てています。 ITチームは、各ユーザーがXNUMXつの企業IPまたは企業ラップトップから一度にログインすることを前提としたネットワークおよびアクセスポリシーを設定しています。 セキュリティチームは、ユーザーIDに基づいてイベントを関連付けています。 財務チームは、ユーザーごとのコストレポートと個人のクラウド環境を集約している可能性があります。 クレデンシャルの共有は、とりわけ、これらすべての仮定を損ないます。 これは、オンラインIDの基本的な意味を取り除きます。
実際の例
ローコード/ノーコードの世界に目を向けて、実際のシナリオを調べてみましょう。 大企業では、カスタマーケアチームのインスピレーションを得た従業員であるジェーンは、組織全体の従業員がカスタマーケースに参加すると、通常、サポートケースの履歴や最新の購入など、顧客に関する重要な情報が欠落していることに気付きました。 ケースが問題に対処できる適切な従業員にルーティングされる間、顧客は問題を何度も説明する必要があるため、これは顧客のエクスペリエンスを低下させます。
これを改善するために、ジェーンは、会社の従業員が顧客のサポートケースに対処する責任のあるチームの一員である場合に、顧客に関するこの重要な情報を表示できるアプリを作成しました。 まず、ローコード/ノーコードの力を認識してみましょう。これにより、ジェーンは予算を要求したりITリソースの割り当てを待たずに、ニーズを特定して対処することができます。
アプリケーションを構築する際、ジェーンは複数の問題を回避する必要がありました。最大の問題は権限です。 組織全体の従業員は、必要な情報を取得するために顧客データベースにクエリを実行するための直接アクセス権を持っていません。 もしそうなら、ジェーンはこのアプリケーションを構築する必要はありません。 この問題を解決するために、ジェーンはデータベースにログインし、認証されたセッションをアプリケーションに直接埋め込みました。 アプリケーションがXNUMX人のユーザーからリクエストを受信すると、アプリケーションはJaneのIDを使用してそのクエリを実行し、結果をユーザーに返します。 このクレデンシャル埋め込み機能、 先月調べたようには、ローコード/ノーコードプラットフォームの重要な機能です。 Janeは、すべてのユーザーが割り当てられた顧客のケースにのみアクセスできるように、アプリケーションに役割ベースのアクセス制御（RBAC）を設定するようにしました。
このアプリケーションは重要なビジネス上の問題を解決したため、企業全体でユーザーにすぐに採用されました。 人々は、会話に適切なコンテキストを設定することで、顧客により良いサービスを提供できることに満足していました。 お客様も喜んでいました。 Janeがアプリケーションを作成してからXNUMXか月後、組織全体ですでに数百人のユーザーが使用しており、顧客満足度が向上しています。
一方、SOCでは、実稼働顧客データベース周辺の異常なアクティビティを示す重大度の高いアラートがトリガーされ、経験豊富なセキュリティアナリストであるエイミーに割り当てられました。 Amyの最初の調査では、内部ユーザーがデータベース全体をスクレイプしようとしており、組織全体の複数のIPアドレスから複数の顧客に関する情報を照会していることがわかりました。 クエリパターンは非常に複雑でした。 データベースがスクレイピングされているときに見られるような単純な列挙パターンの代わりに、同じ顧客のデータが複数回、場合によっては異なるIPアドレスと異なる日付で照会されました。 これは、セキュリティ監視システムを混乱させようとしている攻撃者である可能性がありますか？
簡単な調査の結果、エイミーは重要な情報を発見しました。すべてのIPアドレスと日付にわたるこれらのクエリはすべて、カスタマーケアチームのジェーンという名前の単一のユーザーIDを使用していました。
エイミーはジェーンに連絡を取り、何が起こっているのか尋ねました。 最初、ジェーンは知りませんでした。 彼女の資格情報は盗まれましたか？ 彼女は間違ったリンクをクリックしましたか、それとも間違った受信メールを信頼しましたか？ しかし、ジェーンが最近作成したアプリケーションについてエイミーに話したとき、彼らは両方とも接続があるかもしれないことに気づきました。 SOCアナリストのAmyは、ローコード/ノーコードに精通していなかったため、AppSecチームに連絡しました。 ジェーンの助けを借りて、チームはジェーンのアプリケーションにジェーンの資格情報が埋め込まれていることを理解しました。 データベースの観点からは、アプリケーションはありませんでした。ジェーンだけがいて、たくさんのクエリを実行していました。
Jane、Amy、およびAppSecチームは、解決策が見つかるまでアプリケーションをシャットダウンすることを決定しました。 組織全体のアプリケーションユーザーは、それに依存するようになったために不満を感じ、顧客もそれを感じていました。
エイミーが問題を解決して調査結果を文書化した一方で、カスタマーケア担当副社長は顧客満足度の低下を見て満足していなかったため、ジェーンに恒久的な解決策を探すように依頼しました。 プラットフォームのドキュメントと組織のセンターオブエクセレンスチームの助けを借りて、ジェーンはアプリケーションから埋め込みIDを削除し、各ユーザーのIDを使用してデータベースにクエリを実行するようにアプリを変更し、ユーザーが関連付けられている顧客のケースに対してのみアクセス許可を取得できるようにしました。 。 新しく改良されたバージョンでは、アプリケーションは各ユーザーのIDを使用して顧客データベースにクエリを実行しました。 Janeとアプリケーションのユーザーは、アプリケーションがオンラインに戻ったことに満足し、AmyとAppSecチームは、JaneのIDが共有されなくなったことに満足し、企業は顧客満足度が再び上昇し始めたことを確認しました。 すべてが順調でした。
XNUMX週間後、SOCは、実稼働顧客データベースへの異常なアクセスに関する別のアラートを受信しました。 同じデータベースの以前のアラートと疑わしいほど似ているように見えました。 この場合も、組織全体のIPアドレスは、単一のユーザーのIDを使用してデータベースにクエリを実行していました。 繰り返しますが、そのユーザーはジェーンでした。 しかし今回、セキュリティチームとジェーンは、アプリがユーザーのIDを使用していることを知っていました。 どうしたの？
調査の結果、元のアプリには 暗黙的に共有 アプリのユーザーとのジェーンの認証済みデータベースセッション。 アプリをユーザーと共有することで、そのユーザーは 接続、ローコード/ノーコードのプラットフォームによって提供される認証済みデータベースセッションのラッパー。 その接続を使用して、ユーザーは認証されたセッションを直接活用できます。ユーザーはアプリを経由する必要がなくなりました。 何人かのユーザーがこれを発見し、これが意図された動作であると考えて、ジェーンの認証されたデータベースセッションを使用してクエリを実行していたことが判明しました。 接続を使用すると、割り当てられている顧客のケースだけでなく、データベースへのフルアクセスが直接提供されるため、彼らはこのソリューションを気に入っていました。
接続が削除され、インシデントは終了しました。 SOCアナリストは、ジェーンの接続を使用したユーザーに連絡を取り、保存した顧客データをすべて破棄したことを確認しました。
ローコード/ノーコードセキュリティの課題への対処
上記の話は、多国籍B2C企業の実際のシナリオです。 プライバシーを保護するために、一部の詳細が省略または調整されました。 善意のある従業員が無意識のうちに他のユーザーと自分のIDを共有し、IT、セキュリティ、およびビジネス全体でさまざまな問題を引き起こす可能性があることを確認しました。 先月調査したように、クレデンシャルの共有はローコード/ノーコードの重要な機能です。 それは例外ではなく、標準です。
As ローコード/ノーコードは、意識的かどうかにかかわらず、企業内で開花し続けています、セキュリティチームとITチームがビジネス開発の会話に参加することは非常に重要です。 ローコード/ノーコードアプリには、 独自の一連のセキュリティ課題、そしてそれらの多作な性質は、それらの課題がかつてないほど急速に深刻になることを意味します。
