セキュリティのためのあいまいなURLの使用
私のホスティングプロバイダーは、Webインターフェイスを介して管理されるサービスとしてのインフラストラクチャ（IaaS）製品を提供しており、管理者は仮想マシンを作成および破棄できます。
Webベースの管理ポータルにアクセスするには、ホスティングプロバイダーの「サービスデスク」（HTTPSを介したユーザー名とパスワード）にログインし、生成されたリンクをクリックしてIaaS管理ポータル（HTTPSも）にアクセスする必要があります。
リンク自体は推測できない可能性が高いです（md5ハッシュと2つのGUIDのようなものを含みます）が、そのURLへのアクセス権を持つ人は何時間もIaaSポータルに無制限にアクセスできます（リンクはその後有効期限が切れると思われます）。
リンク経由のアクセスが特定のIPアドレスに制限されていないことをテストしました。
つまり、リンクを知っている人なら誰でも、生成されてから数時間以内にアクセスできる限り、すべてのVMとクライアントのデータを削除できます。
これはIaaSポータルのようなものには不十分なセキュリティですか？ホスティングプロバイダーに具体的にどのような懸念を提起できますか？
編集：この質問は 秘密が含まれているGUID Obscurityを介したURLセキュリティに含まれていますか？ ですが、その質問は低レベルのHTTPクライアントに関連しています。ブラウザーではなく、URLリーク、ブラウザー履歴、キャッシングなどの追加の懸念が生じます。
シークレットURLの問題は、さまざまな方法でリークされる可能性があることです。
画像、JavaScript、スタイルシート、およびフォントは、アクセスしているWebページのURLを漏洩する可能性があります。たとえば、シークレットページに<img src="http://example.com" />次に、ブラウザが画像を取得すると、Refererヘッダーに秘密ページへのURLが含まれる場合があります。ブラウザーがヘッダーを送信できないようにするいくつかの使用例（httpsからhttpへのトラフィック、またはブラウザーのオーバーライド）がありますが、通常、これは秘密URLが漏洩する一般的な方法です。
ページをロードするときに、独自のネットワークトラフィックを監視して（ChromeまたはFirefoxの「ネットワークプロファイル」機能を使用）、URLがリークしているかどうかを確認できますが、主な問題は、ページがリークを引き起こす可能性があります。
リークされた秘密URLの2つの注目度の高いケースには、 Google Docs と Dropbox が含まれます。
これは、IaaSポータルのようなものには不十分なセキュリティですか？
上で述べたように、ブラウザのネットワークプロファイル機能を使用して、ページがURLをリークしているかどうかをテストできます。ただし、最大の懸念はこのシステムの脆弱性です。パスワードのようなものとは異なり、ユーザーはWebページの実装を制御できず、誤って外部リソースをスタイルシートに含めるのは非常に簡単です。これは、システムが安全でないと言っているのではなく、少し壊れやすいということです。
IaaSポータルを使用している場合は、簡単にリークされるURL以外の追加のアクセス制御メカニズムを含めるように依頼します。