認証情報の漏洩による不正アクセスリスクを軽減する方法 - Object Storage Service

個人または企業のユーザーの AccessKey ペアが漏洩すると、Object Storage Service (OSS) リソースへのアクセス権限を持たないユーザーによるリソース操作が可能となり、データセキュリティが脅かされます。この問題に対処するため、OSS はデータセキュリティを確保するためのベストプラクティスを提供しています。

重要

以下のベストプラクティスは一般的なセキュリティ対策であり、完全なセキュリティソリューションではありません。これらのベストプラクティスは参考として提供するものであり、お客様のビジネスシナリオに適していない場合があります。データセキュリティの脅威を常に認識し、必要な予防策を講じることを推奨します。

バケットまたはオブジェクト ACL のプライベート設定

お客様のビジネスにおいて、匿名ユーザーを含むすべてのユーザーによる OSS リソースの読み書きが必要な場合を除き、バケットまたはオブジェクトのアクセス制御リスト (ACL) をパブリック読み取りまたはパブリック読み取り/書き込みに設定しないでください。たとえば、バケットの ACL をパブリック読み取りまたはパブリック読み取り/書き込みに設定すると、以下のようになります。

パブリック読み取り/書き込み：匿名ユーザーを含むすべてのユーザーが、バケット内のオブジェクトの読み書きができます。

警告
すべてのインターネットユーザーがバケット内のオブジェクトにアクセスし、データを書き込めます。これにより、データ漏洩や予期しない高額な料金が発生する可能性があります。ユーザーが禁止されているデータや情報をバケット内のオブジェクトに書き込んだ場合、お客様の正当な権利や利益が損なわれる可能性があります。やむを得ない場合を除き、バケットの ACL をパブリック読み取り/書き込みに設定しないことを推奨します。
パブリック読み取り：バケットの所有者のみがバケット内のオブジェクトにデータを書き込むことができます。匿名ユーザーを含む他のユーザーは、バケット内のオブジェクトからデータを読み取ることができます。

警告
すべてのインターネットユーザーがバケット内のオブジェクトにアクセスできます。これにより、データ漏洩や予期しない高額な料金が発生する可能性があります。バケットの ACL をパブリック読み取りに設定する際は、十分にご注意ください。

説明

AccessKey ペアが漏洩した場合、攻撃者は所有者の有効な認証情報を保持していることになります。バケット ACL がパブリック読み取りに設定されていても、攻撃者は漏洩したAccessKey ペアを使用してDeleteObject を呼び出し、バケット内のオブジェクトを削除できます。パブリック読み取り ACL は、匿名ユーザーによるアクセスのみを制御するものであり、有効なAccessKey ペアを保持する認証済みユーザーが実行する操作を制限するものではありません。AccessKey ペアが漏洩した場合は、直ちに漏洩したAccessKey ペアを無効化し、バケットのリソース変更ログを確認してください。

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

複数の方法でオブジェクトの ACL またはバケットの ACL をプライベートに設定できます。詳細については、「バケット ACL」と「オブジェクトの ACL の設定」をご参照ください。

プレーンテキストの AccessKey ペアのコードへの記述と、暗号化済み AccessKey ペアのローカル保存の回避

コード内のプレーンテキストの AccessKey ペアは、コードと一緒に漏洩する可能性があります。ローカルで暗号化して保存された AccessKey ペアも安全ではありません。なぜなら、暗号化・復号されたコンテンツはメモリに保存されるため、メモリダンプなどにより別のデバイスに保存される可能性があるためです。モバイルアプリやコンピューター上のアプリケーションは、これらのリスクにさらされやすいです。攻撃者は、インジェクション、API フック、動的デバッグなどの技術を使用するだけで、復号されたデータを取得できます。

コード内のプレーンテキストの AccessKey ペアを避けるために、サーバー上で Alibaba Cloud SDK のマネージドシークレットプラグインを使用できます。これにより、ソースコードやコンパイル済みコードと一緒に AccessKey ペアが漏洩するのを防ぐことができます。Alibaba Cloud SDK のマネージドシークレットプラグインの詳細については、「Managed secret plug-in for Alibaba Cloud SDKs」をご参照ください。

重要

この方法はクライアントには適用されません。クライアントに AccessKey ペアを埋め込まないでください。

RAM ユーザーを使用した OSS へのアクセス

Alibaba Cloud アカウントの AccessKey ペアには、すべての API 操作に対する権限があります。これらの認証情報を使用して OSS で操作を実行することは、リスクの高い操作です。RAM ユーザーを使用して API 操作を呼び出すか、定常的な O&M を実行することを推奨します。

RAM ユーザーを作成し、RAM ユーザーに異なる権限を付与して、リソースへのアクセスを管理できます。RAM は、企業内の複数のユーザーがクラウドリソースを共同で管理する必要があるシナリオで、Alibaba Cloud アカウントとパスワードの機密性を厳密に保つのに役立ちます。また、データセキュリティを確保するために、ユーザーに必要最小限の権限を付与することもできます。詳細については、「RAM ユーザーの作成」をご参照ください。

RAM ユーザーを作成した後、RAM ポリシーを使用して RAM ユーザーに権限を付与できます。これにより、従業員、システム、アプリケーションなどのユーザー、およびそれらのユーザーがアクセスできるリソースを管理できます。たとえば、次の RAM ポリシーを使用して、特定の RAM ユーザーが examplebucket という名前のバケットおよび examplebucket バケット内のオブジェクトやディレクトリにアクセスすることを禁止できます。

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "oss:*",
            "Resource": [
                "acs:oss:*:*:examplebucket",
                "acs:oss:*:*:examplebucket/*"
            ]
        }
    ]
}

また、RAM ポリシーを使用して、RAM ユーザーがバケット内のディレクトリを削除できないようにしたり、RAM ユーザーにバケット内のリソースの読み取りのみを許可したりすることもできます。詳細については、「RAM ポリシーの一般的な例」をご参照ください。

MFA の有効化

多要素認証 (MFA) は、使いやすく効果的な認証方法です。MFA を有効にすると、Alibaba Cloud マネジメントコンソールにログインする際に、ユーザー名とパスワードに加えて、MFA デバイスによって生成される動的検証コードが必要になります。これにより、パスワードが漏洩した場合でも、不正アクセスをブロックして Alibaba Cloud アカウントのセキュリティを確保できます。

Alibaba Cloud アカウントで MFA を有効にできます。詳細については、「Alibaba Cloud アカウントへの MFA デバイスのバインド」をご参照ください。RAM ユーザーに対して MFA を有効にすることもできます。詳細については、「RAM ユーザーへの MFA デバイスのバインド」をご参照ください。

STS が提供する一時的なアクセス認証情報を使用した OSS へのアクセス

Security Token Service (STS) を使用して一時的なアクセス認証情報を生成し、特定の期間内に RAM ユーザーに OSS リソースへのアクセスを許可できます。これにより、AccessKey ペアを共有する必要がなくなり、より高いデータセキュリティが確保されます。

STS が提供する一時的なアクセス認証情報を使用して OSS にアクセスする方法の詳細については、「STS が提供する一時的な認証情報を使用して OSS にアクセスする」をご参照ください。

バケットポリシーの設定

バケットポリシーを設定して、他のユーザーにバケット内の特定の OSS リソースへのアクセス権限を付与できます。たとえば、バケットポリシーを設定して、他のアカウントにバケット内のすべてのリソースまたは一部のリソースへのアクセス権限または管理権限を付与できます。また、バケットポリシーを設定して、同じアカウントの異なる RAM ユーザーに異なる権限を付与することもできます。

バケットポリシーを設定する際は、セキュリティリスクを軽減するために最小権限の原則 (PoLP) に従ってください。

バケット内全リソースへのアクセス権限付与の回避

過剰な権限や不正なアクセスを防ぐために、必要なリソースパスに対してのみ権限を付与することを推奨します。
匿名アクセスの不許可

エンドポイントとバケット名が分かれば、匿名アカウントを使用して OSS にアクセスできます。しかし、エンドポイントは列挙可能であり、バケット名はアカウントがアクセスできるオブジェクトの URL から取得できます。したがって、匿名アクセスはセキュリティリスクを増大させます。
[Action] の指定

OSS コンソールでバケットポリシーを設定する際、4 つの認可操作を提供する Action は、ユーザーがポリシーを設定するための便利な方法にすぎず、指定されたアクションがお客様のビジネス要件を満たさない場合があります。詳細設定を使用して、ユーザーに必要な権限のみを付与することをお勧めします。例えば、読み取り専用権限には oss:ListObjects と oss:GetObject が含まれます。ほとんどのシナリオでは、オブジェクトをダウンロードする場合、oss:GetObject 権限のみが必要です。
HTTPS アクセスの有効化

HTTPS を有効にすることで、中間者攻撃やドメインハイジャックなどの問題を解決できます。さらに、Google Chrome を使用して HTTPS の Web サイトを閲覧する場合、その Web サイトの HTTP リソースはデフォルトで読み込まれません。必ず HTTPS を有効にしてください。HTTPS は、さまざまな問題を解決するための最も費用対効果の高い方法です。
ソース IP アドレスの指定

OSS リソースへのアクセスに使用される IP アドレスが固定されており、特定できる場合は、IP アドレスを設定することを推奨します。

たとえば、バケットポリシーを使用して、Test RAM ユーザーに、OSS SDK またはコマンドラインツール ossutil を使用して examplebucket の log ディレクトリ内のすべてのオブジェクトをダウンロードする権限を付与できます。

[Action] を [詳細設定] に設定し、oss:GetObject を選択します。 [Effect] を [許可] に設定します。 [条件] セクションで、[アクセス方法] に HTTPS を選択し、 [IP =] に 10.10.10.10 と入力します。その後、[OK] をクリックします。