すべてのプロダクト
Search
ドキュメントセンター

Object Storage Service:悪意のあるアクセストラフィックによって引き起こされる予期せぬ高額な料金のリスクを軽減

最終更新日:Sep 23, 2024

Object Storage Service (OSS) バケットが攻撃されたり、不正なトラフィックが発生したりすると、帯域幅またはトラフィックスパイクが発生します。 これにより、ストレージ料金が通常よりも予想外に高くなります。 セキュリティリスクと予期しない請求を防ぐために、このトピックで提供されているセキュリティのベストプラクティスを使用してバケットを保護することを推奨します。

重要

以下のベストプラクティスは一般的な手段であり、完全なセキュリティソリューションではありません。 ベストプラクティスは参照用にのみ提供されており、ビジネスシナリオには適していない場合があります。 データセキュリティの脅威を認識し、必要な予防措置を講じることをお勧めします。

予想外に高い料金

バケットが攻撃されたり、不正なトラフィックが発生したりすると、次の財務結果が発生する可能性があります。

  • 高額課金: 追加のOSSトラフィック帯域幅が消費され、消費された帯域幅リソースに対して課金されます。

  • マイナスのアカウント残高: 課金サイクルや課金処理の遅延などの要因により、従量課金制でOSSを使用している場合、アカウントの残高がゼロになってもサービスはすぐに中断されません。 これにより、マイナスのアカウント残高が発生します。 バケットが攻撃されたり、不正なトラフィックが発生したりすると、帯域幅またはトラフィックスパイクが発生します。 合計金額がAlibaba Cloudアカウントの残高よりも高い料金が請求されます。

ブロックパブリックアクセス

バケットポリシーとアクセスコントロールリスト (ACL) を設定することで、OSSリソースへのパブリックアクセスを許可できます。 パブリックアクセスでは、特定の権限や認証なしでOSSリソースにアクセスできます。 パブリックアクセスは、データ侵害を引き起こし、悪意のあるアクセスによりインターネット上に大量のアウトバウンドトラフィックを生成する可能性があります。 パブリックアクセスによって引き起こされるリスクを防ぐために、OSSでは、OSS、バケット、アクセスポイント、およびObject FCアクセスポイントに対して、いくつかの手順でブロックパブリックアクセスを有効にできます。 ブロックパブリックアクセスを有効にすると、既存のパブリックアクセス権限は無視され、パブリックアクセス権限を設定できません。 これにより、パブリックデータアクセスチャネルが無効になり、データセキュリティが確保されます。 詳細については、「パブリックアクセスのブロック」をご参照ください。

PrivateLinkを使用したOSSへのアクセス

PrivateLinkは、仮想プライベートクラウド (VPC) とOSS間のプライベートで安定した安全な接続を確立するために使用されます。 PrivateLinkは、インターネット経由でサービスにアクセスすることで発生するリスクを防ぎます。 この方法は、データのセキュリティを向上させるだけでなく、不正なトラフィックによる大きな経済的損失の可能性を減らします。 次の項目では、PrivateLinkを使用する利点について説明します。

  • 分離: PrivateLinkを使用して、VPCからOSSリソースにアクセスできます。 これにより、OSSをインターネットから分離できます。 OSSリソースには、明示的に権限付与したVPCからのみアクセスできます。 これにより、インターネットを介した悪意のあるアクセスや攻撃を防ぎます。

  • 権限管理: VPCのPrivateLinkエンドポイントを使用して、OSSリソースへのアクセスをきめ細かく管理できます。 たとえば、特定のIPアドレスまたはサブネットからのアクセスを制限したり、特定のセキュリティグループルールを指定してセキュリティをさらに強化したりできます。

  • トラフィックモニタリング: VPCにサービスをデプロイすると、ネットワークトラフィックをより適切に監視および管理し、異常なトラフィックをできるだけ早く検出して処理し、悪意のあるアクセスによって引き起こされるリスクを防ぐことができます。

詳細については、「PrivateLinkを使用したOSSへのアクセス」をご参照ください。

バケットまたはオブジェクトのACLをprivateに設定する

匿名ユーザーを含むすべてのユーザーがOSSリソースからデータを読み書きする必要がない限り、バケットまたはオブジェクトのアクセス制御リスト (ACL) をpublic-readまたはpublic-read-writeに設定しないでください。 たとえば、バケットのACLをpublic-readまたはpublic-read-writeに設定した場合、次の変更が有効になります。

  • Public-read-write: 匿名ユーザーを含むすべてのユーザーが、バケット内のオブジェクトからデータを読み書きできます。

    警告

    これにより、バケット内のデータへの無制限のアクセスと、予想外に高い料金が発生する可能性があります。 ユーザーが禁止データをバケットにアップロードすると、正当な利益と権利が侵害される可能性があります。 必要な場合を除き、バケットACLをpublic-read-writeに設定しないことをお勧めします。

  • 公開読み取り: バケット内のオブジェクトにデータを書き込むことができるのはバケット所有者だけです。 匿名ユーザーを含む他のユーザーは、バケット内のオブジェクトからのみデータを読み取ることができます。

    警告

    これにより、バケット内のデータへの無制限のアクセスと、予想外に高い料金が発生する可能性があります。 バケットACLをpublic-readに設定する場合は注意してください。

パブリック読み取りアクセスまたはパブリック読み取り /書き込みアクセスを許可するバケットまたはオブジェクトは、データ侵害につながる可能性があります。 そのため、オブジェクトACLまたはバケットACLをprivateに設定することを推奨します。 バケットACLをprivateに設定した場合、バケット所有者のみがバケット内のオブジェクトからデータを読み書きできます。 したがって、オブジェクトACLまたはバケットACLをprivateに変更する前に、ビジネスに影響がないことを確認してください。

詳細については、「バケットACL」および「オブジェクトのACLの設定」をご参照ください。

CloudMonitorアラートルールの設定

アラートルールを作成して、OSSリソースの使用状況とステータスを監視できます。 アラートルールがトリガーされると、CloudMonitorはアラート通知を送信し、例外をできるだけ早くチェックして処理できるようにします。

たとえば、バケットのアラートルールを設定できます。 インターネット上のインバウンドおよびアウトバウンドトラフィック、CDNからのインバウンドトラフィック、CDNへのアウトバウンドトラフィックなどのリソース使用量が、1分間などの特定のサイクルで100 MB以上の場合、アラートルールがトリガーされます。 この場合、CloudMonitorはSimple Log Serviceで指定されたLogstoreにアラート情報を書き込みます。

次の図は、インターネット上のインバウンドトラフィックが100 MB以上の場合にトリガーされるアラートルールを設定する方法を示しています。

alert.jpg

Alibaba Cloudアカウントに属するバケットまたはすべてのOSSリソースのアラートルールを設定できます。 詳細については、「アラートルールの作成」をご参照ください。

ホットリンク保護の設定

OSSでは、リファラーベースのフィルタリングポリシーを設定して、特定のリファラーを含むリクエストがバケット内のデータにアクセスするのをブロックできます。 これにより、不正アクセスや予期しないトラフィック料金を防ぐことができます。

ブラウザがバケット内のオブジェクトにアクセスするリクエストを送信すると、リクエストの送信元を指定するRefererヘッダーがリクエストに含まれます。 バケットにホットリンク保護が設定されている場合、OSSはリクエスト内のRefererをバケットのReferer設定と比較します。

  • リクエストのRefererがRefererブラックリストに含まれているか、Refererホワイトリストに含まれていない場合、リクエストは拒否されます。

  • リクエストのリファラーがリファラーホワイトリストに含まれている場合、リクエストは許可されます。

image

たとえば、https:// 10.10.10.10はバケットのリファラーホワイトリストに含まれ、test.jpgイメージはバケットに保存されます。

  • ユーザーAは、test.jpg画像をhttps:// 10.10.10.10 Webサイトにリンクします。 Webサイトから画像が要求されると、ブラウザはRefererヘッダーの値がhttps:// 10.10.10.10である要求を送信します。 リクエストのリファラーヘッダーの値がリファラーホワイトリストに含まれているため、OSSはリクエストを許可します。

  • ユーザーBは、test.jpgイメージをhttps:// 192.168.0.0 Webサイトにリンクします。 Webサイトから画像が要求されると、ブラウザはRefererヘッダーの値がhttps:// 192.168.0.0である要求を送信します。 リクエストのリファラーヘッダーの値がリファラーホワイトリストに含まれていないため、OSSはリクエストを拒否します。

詳細については、「ホットリンク保護」をご参照ください。

CORS ルールの設定

クロスオリジンリソース共有 (CORS) は、webアプリケーションサーバーがクロスオリジンアクセスを制御できるようにするためにHTML5によって提供される標準のクロスオリジンソリューションです。 これにより、オリジン間のデータ伝送のセキュリティが確保されます。 ブラウザは、同じオリジンのポリシーメカニズムを使用して、潜在的に悪意のあるデータを分離し、クロスオリジンリクエストをデフォルトで拒否します。 たとえば、あるWebサイトのJavaScriptコードが別のWebサイトでホストされているリソースをリクエストした場合、ブラウザはそのリクエストを拒否します。

要件に基づいて、クロスオリジンリクエストを許可または拒否するようにCORSルールを設定できます。 たとえば、次の図に示すCORS設定を使用して、www.aliyun.comからバケットへのHTTP GETリクエストを許可できます。

cors

詳細については、「CORS の設定」をご参照ください。

シーケンシャルプレフィックスによるオブジェクトの命名を避ける

多数のオブジェクトをアップロードし、タイムスタンプや文字、日付、参照可能な数値IDなどのシーケンシャルプレフィックスを使用して名前を付けると、攻撃者は名前のルールを把握し、すべてのオブジェクトを取得するためのスクリプトを作成できます。 これは、データ漏洩の原因となる。 この場合、タイムスタンプ桁の順序を逆にして、オブジェクト名またはオブジェクト名に16進ハッシュプレフィックスを追加することをお勧めします。 これにより、オブジェクト名がトラバースされるリスクを低減することができる。 詳細については、「OSSパフォーマンスとスケーラビリティのベストプラクティス」をご参照ください。