CSA クラウドの攻撃ベクトルを理解する (2023.06.06)
こんにちは、丸山満彦です。
IaaS/Paasにおけるクラウドベースの攻撃を効果的、効率的に守るためのアイデアといったところですかね。。。CSAのイスラエルが頑張ったようですね。。。
・2023.06.06 Understanding Cloud Attack Vectors
| Understanding Cloud Attack Vectors | クラウドの攻撃ベクトルを理解する |
| The goal of the document is to map the various attack vectors that are actually being used during cloud-based attacks in IaaS/PaaS and to map the vectors and their mitigating controls to various resources. The motivation for this document came after we analyzed much research around cloud security and realized that they are listing a combination of risks, threats, attack vectors, vulnerabilities, and concerns. And while there are many risks and threats to IaaS/PaaS platforms and applications, most of the risks are associated with a very specific number of attack vectors. | この文書の目的は、IaaS/PaaSにおけるクラウドベースの攻撃で実際に使用されている様々な攻撃ベクトルをマッピングし、そのベクトルとその低減対策を様々なリソースにマッピングすることである。このドキュメントを作成した動機は、クラウドセキュリティに関する多くの研究を分析した結果、リスク、脅威、攻撃ベクトル、脆弱性、懸念事項の組み合わせがリストアップされていることに気づいたからだ。そして、IaaS/PaaSプラットフォームやアプリケーションには多くのリスクや脅威が存在するが、ほとんどのリスクは非常に特定の数の攻撃ベクトルに関連している。 |
・報告書
目次的...
| 1: Exploitable Workloads | 1: 搾取可能なワークロード |
| 2: Workloads with Excessive Permissions | 2: 過大な権限を持つ作業負荷 |
| 3: Unsecured Keys, Credentials, and Application Secrets | 3: 安全でない鍵、認証情報、アプリケーションシークレット |
| 4: Exploitable Authentication or Authorization | 4: 悪用可能な本人認証または認可 |
| 5: Unauthorized Access to Object Storage | 5: オブジェクト・ストレージへの不正アクセス |
| 6: Third-Party Cross-Environment/Account Access | 6: サードパーティによるクロス環境/アカウントアクセス |
| 7: Unsecured/Unencrypted Snapshots & Backups | 7: 安全でない/暗号化されていないスナップショットとバックアップ |
| 8: Compromised Images | 8: 危殆化したイメージ |
・要約
ポイントをしぼって仮対訳...
↓↓↓↓↓↓↓↓↓↓
概要...
| 1: Exploitable Workloads | 1: 搾取可能なワークロード |
| Definition | 定義 |
| A workload is defined by CSA as a “unit of processing, which can be in a virtual machine, a container, or other abstraction” (CSA Security Guidance 4, 7.4). Exploitable workloads are an attack vector that details an attacker’s ability to exploit a workload’s vulnerabilities and gain initial footholds into the cloud environment. The vulnerability can be either well-known or zero-day. In both cases, if not mitigated, this kind of initial access into the cloud environment can increase the realization of the risk related to the attack vector. One of the more common implications of this attack method is leveraging this into running crypto miners or ransomware attacks. In other cases, advanced techniques are used to pivot in the environment using attached or stored cloud credentials to gain data access or perform privilege escalation and lateral movement within the cloud environment. | CSA では、ワークロードを「仮想マシン、コンテナ、またはその他の抽象化された処理単位」と定義している（CSA Security Guidance 4, 7.4）。攻撃可能なワークロードは、攻撃者がワークロードの脆弱性を悪用し、クラウド環境への最初の足がかりを得るための攻撃ベクトルである。脆弱性には、既知のものとゼロデイ脆弱性がある。いずれの場合も、低減されなければ、クラウド環境へのこの種の初期アクセスは、攻撃ベクトルに関連するリスクの認識を高める可能性がある。この攻撃手法の一般的な意味合いとしては、暗号マイナーの実行やランサムウェア攻撃への活用が挙げられる。また、高度なテクニックを使って、添付または保存されているクラウド認証情報を使ってクラウド環境をピボットし、データにアクセスしたり、クラウド環境内で特権の昇格や横方向の移動を行ったりするケースもある。 |
| Description | 説明 |
| Exploitable workloads refer to any virtual machine or container accessible to an internal or external attacker due to misconfiguration of the cloud networks. Accessibility is achieved if the workload has a public IP address or the attacker already has access to the internal environment. “Exploitable workload” means the asset is vulnerable to misconfigurations, has known Common Vulnerability and Exposures (CVEs), application vulnerabilities, and so on. Using the combination of both access and existing vulnerability, an attacker can successfully obtain access, control, or leverage the cloud workload to further their attack. In this attack vector, the compromised asset can lead to the attacker achieving persistence, data access, or privilege escalation in the cloud environment. The attacker can then leverage this asset to strengthen access and control to perform lateral movements in search of additional assets. | 悪用可能なワークロードとは、クラウドネットワークの設定ミスにより、内部または外部の攻撃者がアクセス可能な仮想マシンやコンテナを指す。アクセス可能とは、ワークロードがパブリックIPアドレスを持つか、攻撃者がすでに内部環境にアクセスできる場合である。「エクスプロイト可能なワークロード」とは、そのアセットが設定ミスに対して脆弱であること、既知の共通脆弱性エクスポージャー（CVE）、アプリケーションの脆弱性などがあることを意味する。攻撃者は、アクセスと既存の脆弱性の両方を組み合わせることで、クラウドワークロードへのアクセス、制御、活用を成功させ、攻撃を進めることができる。この攻撃ベクトルでは、侵害されたアセットによって、攻撃者はクラウド環境における永続性、データアクセス、権限の昇格を達成することができる。攻撃者はその後、この資産を活用してアクセスと制御を強化し、さらなる資産を求めて横の動きを行うことができる。 |
| Key Takeaways | 要点 |
| To harden the cloud environment, security should occur across all points of the attack path. | クラウド環境を強固にするためには、攻撃経路のすべてのポイントでセキュリティを確保する必要がある。 |
| · Network: Limit network access as much as possible, preferably private subnets and using security groups and micro segmentation. Use IP restrictions to specifically designate Classless Inter-Domain Routing (CIDR) ranges and open access to selected ports instead of ranges that are too wide. Whenever possible, expose services using a security barrier, such as a Load balancer, API Gateways, and/or a Web application firewall (WAF). | ・ネットワーク： 可能な限りネットワーク・アクセスを制限する。できればプライベート・サブネットを使用し、セキュリティ・グループとマイクロ・セグメンテーションを使用する。IP制限を使用してCIDR（Classless Inter-Domain Routing）範囲を具体的に指定し、広すぎる範囲ではなく、選択したポートへのアクセスを開放する。可能な限り、ロードバランサー、APIゲートウェイ、Webアプリケーションファイアウォール（WAF）などのセキュリティバリアを使ってサービスを公開する。 |
| · Vulnerabilities: Scan all workloads regularly to detect known vulnerabilities and fix them through suggested remediation. Conducting a security assessment dedicated to the organization’s cloud environment is also recommended to ensure the discovery of unknown risks. Keep in mind that different workloads require different vulnerability scanning tools (i.e., containers might require different tools over VMs). A vulnerability scan should be performed using automated tools (Software Composition Analysis tools to detect vulnerabilities in open source packages, SAST/DAST/IAST (depending on your application type) to detect vulnerabilities in code, and so on) and be embedded as part of the continuous integration/continuous delivery (CI/CD) process. | ・脆弱性： すべてのワークロードを定期的に検知して既知の脆弱性を検出し、推奨される改善策によって修正する。未知のリスクを確実に発見するために、組織のクラウド環境に特化したセキュリティアセスメントを実施することも推奨される。ワークロードが異なれば、脆弱性スキャンツールも異なることに留意する（例えば、コンテナはVMとは異なるツールを必要とするかもしれない）。脆弱性スキャンは、自動化ツール（オープンソースパッケージの脆弱性を検知するためのソフトウェア構成分析ツール、コードの脆弱性を検知するためのSAST/DAST/IAST（アプリケーションの種類による）など）を使用して実行し、継続的インテグレーション／継続的デリバリー（CI/CD）プロセスの一部として組み込むべきである。 |
| · Identity and Access Management (IAM): All access to resources by identities must be authenticated and authorized. Follow the principle of least privilege/need to know and provide the minimum required permissions to the workloads that allow them to perform their designated task and store application secrets in a secure location. | ・アイデンティティとアクセス管理(IAM): 本人認証によるリソースへのアクセスはすべて認証され,許可されなければならない。最小特権/知る必要の原則に従い,ワークロードが指定されたタスクを実行できるように,必要最小限の権限をプロバイダに提供し,アプリケーションの秘密を安全な場所に保管する。 |
| · Application: Ensure design of the applications is in accordance with accepted principles for secure development, including auto-patching. | ・アプリケーション: アプリケーション:アプリケーションの設計が,自動パッチ適用を含め,安全な開発のために受け入れら れている原則に従っていることを確認する。 |
| 2: Workloads with Excessive Permissions | 2: 過大な権限を持つ作業負荷 |
| Definition | 定義 |
| The following attack vector describes a workload with excessive permissions in a cloud environment. In cloud environments, workloads such as VMs or containers often receive an identity or a role to perform operations on the cloud infrastructure. A typical example is providing a role to a VM, allowing access to cloud storage. By following this vector, attackers with access to the workload can leverage their permissions and gain excessive permissions to the environment. | 以下の攻撃ベクターは、クラウド環境における過剰なパーミッションを持つワークロードについて記述している。クラウド環境では、VMやコンテナなどのワークロードは、クラウドインフラストラクチャ上で操作を実行するためのIDやロールを受け取ることが多い。典型的な例は、クラウドストレージへのアクセスを許可するロールをVMに提供することである。このベクトルに従うことで、ワークロードにアクセスできる攻撃者は、その権限を活用し、環境に対する過剰な権限を得ることができる。 |
| Description | 説明 |
| A workload is a unit of processing, which can be in a virtual machine, a container, or other abstraction such as serverless or FaaS (Function as a service). Workloads are generally created to run several jobs or tasks, with different access patterns and authentication complexities, requiring different permissions for multiple services. These permissions are assigned to the workload as a policy or role. This complexity creates challenges in managing access to specific services and resources, leading to bad security practices such as granting excessive permissions. | ワークロードは処理の単位であり、仮想マシン、コンテナ、あるいはサーバーレスやFaaS（Function as a Service）のような抽象化されたものである。ワークロードは通常、複数のジョブやタスクを実行するために作成され、アクセスパターンや本人認証の複雑さが異なるため、複数のサービスに対して異なるパーミッションが必要となる。これらのパーミッションは、ポリシーやロールとしてワークロードに割り当てられる。このような複雑さは、特定のサービスやリソースへのアクセス管理に課題をもたらし、過剰なパーミッションの付与といった悪質なセキュリティ慣行につながる。 |
| This attack vector emphasizes the potential for the elevation of privileges. The attacker usually gains first access with low-level permissions, so access to the workload with excessive permissions can result in the elevation of privileges and the attacker gaining better persistence and the ability to create more damage. | この攻撃ベクトルは、特権の昇格の可能性を強調する。攻撃者は通常、低レベルのパーミッションで最初のアクセスを獲得するため、過剰なパーミッションでワークロードにアクセスすると、結果的に特権が昇格し、攻撃者はより優れた永続性を獲得し、より大きな損害を生み出す能力を得ることになる。 |
| Key Takeaways | 要点 |
| · Always implement the principle of least privilege by giving the workloads the minimum permissions necessary to perform their assigned tasks. | ・ワークロードに,割り当てられたタスクを実行するために必要な最小限の権限を与えることで,最小特権の原則を常に実行する。 |
| · Prefer temporary access tokens instead of permanent permissions. | ・永続的なアクセス許可ではなく,一時的なアクセストークンを優先する。 |
| · Prefer customized policy and roles over pre-defined and general roles. | ・あらかじめ定義された一般的なロールよりも,カスタマイズされたポリシーとロールを優先する。 |
| · Try to be more granular in your policies by using features, such as permission boundaries, and assume roles. | ・権限境界や想定ロールなどの機能を使用して,ポリシーをより細かくする。 |
| · Prevent the possibility of activating local user accounts with high privileges, especially when working with containers. | ・特にコンテナで作業する場合,高い権限を持つローカル・ユーザー・アカウントがアクティブになる可能性を防ぐ。 |
| · Verify and audit the permissions of the workloads to ensure that they do not have excessive permissions. | ・ワークロードの権限を検証・監査し,過剰な権限がないことを確認する。 |
| 3: Unsecured Keys, Credentials, and Application Secrets | 3: 安全でない鍵、認証情報、アプリケーションシークレット |
| Definition | 定義 |
| This attack vector details the existence of cleartext credentials or unprotected credentials on a cloud workload, service or code repository. Credentials can be of different types and located in various places. The popular vectors include IAM access or API keys embedded inside a configuration file, template, or actual code. Or SSH keys embedded into an image or workload. These types of credentials are known as secrets. | この攻撃ベクトルは、クラウドのワークロード、サービス、またはコードリポジトリ上に、平文の認証情報または保護されていない認証情報が存在することを詳述する。クレデンシャルには様々なタイプがあり、様々な場所に存在する。よく使われるベクターには、設定ファイル、テンプレート、または実際のコードに埋め込まれたIAMアクセスキーやAPIキーがある。あるいは、イメージやワークロードに埋め込まれたSSHキーである。これらのタイプのクレデンシャルはシークレットとして知られている。 |
| Description | 説明 |
| Cloud services interact among themselves and/or with external services. This interaction requires a set of permissions, so a mechanism of authentication and authorization is involved. This mechanism is activated using API or Access keys that authenticate the consuming service or workload. For example, a known use case is when an EC2 instance needs access to an S3 bucket to store or retrieve data, or a CI service requires an API key to authenticate to an external code repository. | クラウドサービスは、サービス間や外部サービスと相互作用する。この相互作用には一連のパーミッションが必要なので、本人認証と認可のメカニズムが関係する。このメカニズムは、消費するサービスまたはワークロードを認証するAPIキーまたはアクセスキーを使用して起動される。例えば、EC2インスタンスがデータを保存または取得するためにS3バケットにアクセスする必要がある場合や、CIサービスが外部のコードリポジトリを認証するためにAPIキーを必要とする場合などが、よく知られている使用例である。 |
| Another common scenario is using SSH keys to manage a fleet of virtual machines leading to challenges in managing SSH key pairs. Due to the complexity of managing access keys, organizations use the same keys for multiple compute instances. As a result, an attacker that compromises one server can access all servers that use the same SSH key pair. This is an easy way to move inside the cloud environment, gather more information, and search for higher permissions. | もう1つの一般的なシナリオは、SSHキーを使用して仮想マシンのフリートを管理することで、SSHキー・ペアの管理に課題が生じる。アクセス・キーの管理が複雑なため、組織は複数のコンピュート・インスタンスに同じキーを使用している。その結果、1つのサーバーを侵害した攻撃者は、同じSSHキー・ペアを使用しているすべてのサーバーにアクセスできる。これは、クラウド環境内部に移動し、より多くの情報を収集し、より高い権限を探索する簡単な方法である。 |
| Many organizations fail to establish clear policies for secret life cycle management (generate, store, retrieve, rotate, and decommission), resulting in unauthorized access to resources, the ability to perform lateral movement, and the elevation of privileges in the environment. | 多くの組織では、シークレットのライフサイクル管理（生成、保管、回収、ローテーション、破棄）に対する明確なポリシーが確立されておらず、その結果、リソースへの不正アクセス、横移動の実行、環境内での権限の昇格が発生している。 |
| Key Takeaways | 要点 |
| The recommended best practices for storing and using API keys, secrets, passwords, SSH keys, or certificates depend on the actual access scenario. Here are a few examples: | APIキー、シークレット、パスワード、SSHキー、または証明書の保管と使用について推奨されるベストプラクティスは、実際のアクセスシナリオによって異なる。以下にいくつかの例を挙げる： |
| · Cloud provider workload accessing the same provider service: The recommended way to grant this access to the workload is by attaching it to an identity with the required permissions. This will eliminate the need for static access keys and utilize dynamically assigned keys. Examples of this type of solution are AWS STS, GCP OICD, or Azure SAS. | ・クラウド・プロバイダのワークロードが同じプロバイダ・サービスにアクセスする: ワークロードにこのアクセスを許可する推奨の方法は,必要な権限を持つIDにワークロードをアタッチすることである。これにより,静的なアクセス・キーが不要になり,動的に割り当てられるキーを利用できる。この種のソリューションの例としては,AWS STS,GCP OICD,または Azure SAS がある。 |
| · Application components interacting among themselves, or with cloud external services, can store secrets in designated, secure storage. Examples are AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager. | ・アプリケーション・コンポーネント同士,あるいはクラウド外部サービスと相互作用するアプリケーション・コンポーネントは,指定された安全なストレージに秘密を保存することができる。例えば,AWS Secrets Manager,Azure Key Vault,GCP Secret Managerなどがある。 |
| · For SSH keys, secured bastion hosts (“jump box”) with a one-time SSH key, or an IAM-based auth solution (i.e., AWS Session Manager, Azure Bastion, or Google Identity-Aware Proxy) can be used to maximize security. Some enterprise solutions also support MFA alongside the SSH authentication mechanism. It is also recommended to use different SSH keys for different environments and classifications. | ・SSHキーについては、1回限りのSSHキーを持つセキュアなBastionホスト（「ジャンプボックス」）、またはIAMベースの認証ソリューション（AWS Session Manager、Azure Bastion、Google Identity-Aware Proxyなど）を使用して、セキュリティを最大限に高めることができる。エンタープライズソリューションの中には、SSH認証メカニズムとともにMFAをサポートしているものもある。また、環境や分類ごとに異なるSSH鍵を使用することも推奨される。 |
| · Follow secure procedure for any key lifecycle from generation to revocation. | ・鍵の生成から失効まで,鍵のライフサイクルには安全な手順を踏む。 |
| · Store keys in a designated enterprise service (such as AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager). | ・指定されたエンタープライズ・サービス（AWS Secrets Manager、Azure Key Vault、GCP Secret Managerなど）に鍵を保管する。 |
| · Intelligently manage the public distribution process of open source solutions, such as containers publish process to public container registry or code libraries that the organization develops and shares in common open source repositories. | ・オープンソースソリューションの公開配布プロセスをインテリジェントに管理する。たとえば,公開コンテナレジストリへのコンテナの公開プロセスや,組織が開発して共通のオープンソースリポジトリで共有するコードライブラリなどである。 |
| · Monitor access logs to detect any suspicious activity related to access keys and certificates. | ・アクセス・ログを監視し,アクセス・キーや証明書に関連する不審な活動を検知する。 |
| To detect cleartext secrets on different locations, we recommend regularly scanning cloud workload configuration, Infrastructure as Code templates, and code repositories to search for static credentials and keys/secrets. | 異なる場所にある平文の秘密を検出するために、クラウドワークロード構成、Infrastructure as Codeテンプレート、コードリポジトリを定期的にスキャンして、静的な認証情報とキー／秘密を検索することを推奨する。 |
| 4: Exploitable Authentication or Authorization | 4：悪用可能な本人認証または認可 |
| Definition | 定義 |
| This attack vector details an entity’s improper management and authentication, such as user, workload, function, role, group, and so on. Each identity should have security controls and be properly maintained. A neglected identity, one that is not in use for a long time or in no use at all and has excessive permissions can lead to an undetected breach that compromises this identity. | この攻撃ベクトルは、ユーザー、ワークロード、機能、役割、グループなど、事業体の不適切な管理と認証を詳述する。各アイデンティティは、セキュリティ管理され、適切に維持されなければならない。放置された ID、長期間使用されていない ID、まったく使用されていない ID、過剰な権限を持つ ID は、この ID を危険にさらす未検出の侵害につながる可能性がある。 |
| Description | 説明 |
| It is crucial to maintain a healthy security environment. Although this is not an easy task, it is important to pay attention to IAM best practices, as it is usually the first thing attackers will examine and try to exploit. | 健全なセキュリティ環境を維持することは極めて重要である。これは簡単なことではないが、IAMのベストプラクティスに注意を払うことは重要である。なぜなら、IAMは通常、攻撃者が最初に調べ、悪用しようとするものだからである。 |
| Improper management comes in many forms: | 不適切な管理は様々な形で現れる： |
| · Using default password. Some tools are installed with the default password, and administrators fail to change the default password, resulting in security exposure. | ・デフォルトのパスワードを使う。一部のツールはデフォルトのパスワードでインストールされており,管理者はデフォルトのパスワードを変更しないため,セキュリティのエクスポージャーにつながる。 |
| · Weak password policies. Without defining a strong password policy, attackers can easily guess passwords using well-known techniques (dictionary attacks, brute force, etc.) and gain access to the target user’s identity to log in to its cloud environment. | ・パスワード・ポリシーが弱い。強力なパスワード・ポリシーを定義しないと、攻撃者はよく知られたテクニック（辞書攻撃、総当たり攻撃など）を使って簡単にパスワードを推測し、ターゲット・ユーザーのIDにアクセスしてクラウド環境にログインすることができる。 |
| · Empty groups. Groups are aggregated entities usually created for users. In the cloud environment, permissions can be assigned to the group and granted to users. Those permissions are also granted to any users in the group. New users added to the group will also be granted the existing permissions of this group. Therefore, having a group without assigned users imposes a risk on the environment if an attacker gets access to IAM and ability to re-populate this group. | ・空のグループ。グループは通常,ユーザーのために作成される集約された事業体である。クラウド環境では,グループに権限を割り当て,ユーザーに付与することができる。これらの権限は,グループ内のすべてのユーザーにも付与される。グループに追加された新しいユーザーにも,このグループの既存のパーミッションが付与される。したがって,ユーザーが割り当てられていないグループを持つことは,攻撃者がIAMにアクセスし,このグループに再度アクセスできるようになった場合,環境にリスクを課すことになる。 |
| · Excessive permissions. Granting specific permissions to resources can be a tiresome task, this is why it is very common to see users/groups with excessive permissions with no legitimate reason. This security issue can lead to gaining access to sensitive resources and performing actions that can lead to environmental compromise. | ・過剰なパーミッション。リソースに特定のパーミッションを付与するのは面倒な作業であるため,正当な理由もなく過剰なパーミッションを持つユーザー/グループを見かけることは非常に多い。このセキュリティ上の問題は,機密性の高いリソースへのアクセスや,環境侵害につながりかねないアクションの実行につながる可能性がある。 |
| · Not enforcing MFA. Multifactor Authentication (MFA) provides an additional protection layer for users. When MFA is not enabled, and the authentication is performed with static credentials (i.e., username and password), attackers can easily compromise the environment once they gain access to those credentials, such as by phishing. The preferred method is using authenticator apps like Google Authenticator. | ・MFAを実施しない。多要素認証（MFA）は、ユーザーに追加の保護レイヤーを提供する。MFAが有効化されておらず、本人認証が静的な認証情報（ユーザー名とパスワードなど）で実行されている場合、攻撃者は、フィッシングなどで一旦これらの認証情報にアクセスすると、簡単に環境を侵害することができる。Google Authenticatorのような本人認証アプリを使用するのが望ましい。 |
| · Inactive identities. Activities for inactive identities/users can be tracked using audit logs and last login records. Those identities are considered neglected identities that can pose a risk to the environment because, usually, they are not monitored or maintained currently. | ・非アクティブな ID。非アクティブな ID/ユーザのアクティビティは,監査ログと最終ログイン記録を使用して追跡できる。これらのIDは,通常,現在監視または保守されていないため,環境にリスクをもたらす可能性がある放置されたIDと見なされる。 |
| · No Logging. The origination does not log AAA operations resulting in inability to detect malicious use. | ・ログを記録しない。オリジネーションが AAA 操作をログに記録しないため,悪意のある使用を検出できない。 |
| · Misconfigured IAM Trust Policy. Identity and Access Management trust policies to external identities and cross-account access that are misconfigured may be enumerated and lead to initial access to the victim’s cloud account. | ・IAM信頼ポリシーの設定ミス。アイデンティティとアクセス管理の信頼ポリシーが誤って設定されている場合,外部アイデンティティとクロスアカウントアクセスが列挙され,被害者のクラウドアカウントへの初期アクセスにつながる可能性がある。 |
| Key Takeaways | 要点 |
| To proactively prevent this kind of attack path, organizations should: | この種の攻撃経路を未然に防ぐために、組織は以下を行うべきである： |
| · Enable MFA. MFA should be mandatory for all users and all applications. | ・MFAを有効にする。すべてのユーザーとすべてのアプリケーションでMFAを必須にする。 |
| · Create strong password policies. Ensure user passwords won’t be compromised easily. In addition to the standard password policies complexity (length, uppercase, lowercase alphabet, numerical and non-alphanumeric characters), administrators should also set password expirations and configure the settings so that expired passwords require administrator resets and prevent password reuse. | ・強固なパスワード・ポリシーを作成する。ユーザーのパスワードが簡単に漏洩しないようにする。標準的なパスワードポリシーの複雑さ（長さ、大文字、小文字のアルファベット、数字、英数字以外の文字）に加え、管理者はパスワードの有効期限を設定し、有効期限が切れたパスワードは管理者によるリセットが必要になるように設定し、パスワードの再利用を防ぐ。 |
| · Temporary access. Use temporary access (such as AWS Assume Role or Azure Just-in-Time access) instead of static credentials/permissions. | ・一時アクセス。静的なクレデンシャル／権限の代わりに、一時的なアクセス（AWS Assume RoleやAzure Just-in-Timeアクセスなど）を使用する。 |
| · Reevaluate permissions. Audit and monitor policies and make sure to follow the concept of least privileges. | ・権限を再評価する。ポリシーを監査・監視し,最小権限の概念に従うようにする。 |
| · Empty groups. If there are groups without users, delete the group. | ・空のグループを作る。ユーザーのいないグループがある場合,そのグループを削除する。 |
| · Inactive identities. Monitor identity activities using audit logs and last login records. If an identity looks inactive for a defined period (as determined by the organization), it is recommended to delete it. Ensure accounts are removed as part of off-boarding processes. | ・非アクティブなID。監査ログと最終ログイン記録を使用して,IDのアクティビティを監視する。定義された期間(組織によって決定される),IDが非アクティブに見える場合は,そのIDを削除することを推奨する。オフボーディングプロセスの一環としてアカウントが削除されるようにする。 |
| · Enforcing Logging. Enforcing logging and audit on any AAA operations in the cloud and application level. | ・ロギングを強制する。クラウドおよびアプリケーション・レベルでのAAA操作について,ロギングと監査を実施する。 |
| 5: Unauthorized Access to Object Storage | 5：オブジェクト・ストレージへの不正アクセス |
| Definition | 定義 |
| Object storage is one of the most common services in the cloud. Because of its wide-spread use, it is also a known attack vector. This attack vector details the existence of cloud-hosted storage with public objects that don’t require user authentication or authorization, usually by mistake. With no authorization, attackers can exploit it to read and/or write data using common tools to compromise the stored data’s availability, integrity, or confidentiality. | オブジェクト・ストレージは、クラウドで最も一般的なサービスの1つである。広く使用されているため、攻撃ベクターとしても知られている。この攻撃ベクターは、クラウドでホストされているストレージに、本人認証や認可を必要としないパブリック・オブジェクトが存在することを詳しく説明している。認証がないため、攻撃者はこれを悪用して、一般的なツールを使ってデータの読み取りや書き込みを行い、保存されているデータの可用性、完全性、機密性を侵害することができる。 |
| Description | 説明 |
| Cloud object storage is a key factor in any deployment, most applications need some form of storage. Suppose those cloud storages are misconfigured to be publicly reachable without additional authorization. In that case, attackers can use readily available utilities to compromise the datastore and/or the data within, with a high likelihood of attacking without detection. | クラウド・オブジェクト・ストレージはどのような展開においても重要な要素であり、ほとんどのアプリケーションは何らかのストレージを必要としている。これらのクラウドストレージが、追加の認証なしに一般にアクセスできるように誤って設定されているとする。その場合、攻撃者は容易に入手可能なユーティリティを使用して、データストアやその中のデータを侵害することができる。 |
| There are several main security configurations on which object storage services are built: | オブジェクト・ストレージ・サービスが構築されている主なセキュリティ構成はいくつかある： |
| · Public/Private. When discussing public cloud object storage, the differentiation between public and private refers to both network access (via an endpoint or a hostname) and additional identity controls, such as allowing anonymous users to read and/or write from the storage. When creating a storage component in object storage, the user can choose if the storage will be public or private. This configuration controls the access settings of the storage. When access is public, the storage does not require authorization, and any entity can access it without special restrictions. | ・パブリック／プライベート。パブリック／プライベート。パブリッククラウドオブジェクトストレージについて議論する場合、パブリックとプライベートの区別は、（エンドポイントまたはホスト名を介した）ネットワークアクセスと、匿名ユーザーによるストレージの読み取りや書き込みを許可するなどの追加のID制御の両方を指す。オブジェクトストレージでストレージコンポーネントを作成する際、ユーザーはストレージをパブリックにするかプライベートにするかを選択できる。この設定はストレージのアクセス設定を制御する。アクセスがパブリックの場合、ストレージは認証を必要とせず、どの事業体も特別な制限なしにアクセスできる。 |
| · Encryption. Post-incident response reports show that many cloud storage components were public and unencrypted at rest. Cloud-native encryption typically requires additional permissions to use the encryption keys, which can prevent the data itself from being compromised in some cases. | ・暗号化。インシデント発生後の対応報告によると,多くのクラウドストレージコンポーネントは公開され,静止状態では暗号化されていなかった。クラウドネイティブの暗号化では通常,暗号化キーの使用には追加の権限が必要であり,場合によってはデータ自体の漏洩を防ぐことができる。 |
| · Authentication. Some public cloud object storage offers multiple configuration options for the authentication to the resource. Mostly, there are options for no authentication or basic authentication (username and password). Other advanced options include Security Assertation Markup Language (SAML) or OpenID connect (OIDC), or cloud-native IAM-based authentication. The latter authentication methods are more hardened against external attacks than the former. | ・本人認証。パブリック・クラウド・オブジェクト・ストレージの中には、リソースへの本人認証に複数の設定オプションを提供しているものもある。ほとんどの場合、本人認証なし、または基本認証（ユーザー名とパスワード）のオプションがある。その他の高度なオプションとしては、SAML（Security Assertation Markup Language）やOIDC（OpenID connect）、クラウドネイティブなIAMベースの認証などがある。後者の認証方法は、前者よりも外部からの攻撃に対してより強固になっている。 |
| · In addition to these security configurations, there are other preventative measures that can be implemented: | ・これらのセキュリティ設定に加えて、実施可能な予防策がある： |
| · Security Awareness Training. Training users on object storage security awareness is crucial to maintaining the confidentiality, integrity, and availability of sensitive data stored in the cloud. Training can also help users recognize phishing attempts and other social engineering tactics that cybercriminals use to trick users into revealing sensitive information or clicking on malicious links. Ultimately, a well-trained user base can serve as a first line of defen against cyber threats and help ensure the security of an organization’s data. | ・セキュリティ意識向上およびトレーニング。クラウドに保存された機密データの機密性,完全性,可用性を維持するためには,オブジェクト・ストレージのセキュリティに関する意識向上およびトレーニングが不可欠である。トレーニングはまた,サイバー犯罪者がユーザーを騙して機密情報を開示させたり,悪意のあるリンクをクリックさせたりするために使用するフィッシングの試みなどのソーシャル・エンジニアリングの手口をユーザーが認識するのにも役立つ。最終的には,十分に訓練されたユーザー・ベースは,サイバー脅威に対する防御の第一線として機能し,組織のデータのセキュリティを確保するのに役立つ。 |
| · Security Scanning. Security scanning of object storage can be an effective tool for identifying misconfigurations that could leave data vulnerable to attack. By scanning object storage for misconfigured buckets, publicly accessible data, or improperly set access controls, organizations can proactively detect and remediate security issues before they can be exploited by cybercriminals. Regular security scans can be integrated into an organization’s security program to provide ongoing visibility into the security posture of their object storage and help ensure the continued protection of their data. | ・セキュリティ・スキャン。オブジェクトストレージのセキュリティスキャンは,データを攻撃に対して脆弱な状態にする可能性のある誤設定を識別するための効果的なツールとなる。オブジェクトストレージをスキャンして,設定ミスのあるバケット,一般にアクセス可能なデータ,不適切に設定されたアクセス制御を検出することで,組織はサイバー犯罪者に悪用される前に,セキュリティ上の問題をプロアクティブに検出し,修正することができる。定期的なセキュリティ・スキャンを組織のセキュリティ・プログラムに組み込むことで,オブジェクト・ストレージのセキュリティ状況を継続的に可視化し,データの継続的な保護に役立てることができる。 |
| Key Takeaways | 要点 |
| To proactively secure the cloud environment from unauthorized access to object storage attack vectors, the organization can: | オブジェクト・ストレージの攻撃ベクトルへの不正アクセスからクラウド環境をプロアクティブに保護するために、組織は以下のことができる： |
| · Keep all object storage private. If the object storage is not intended to be public or contains any data that is not supposed to be public, the best practice is to change the settings of the storage asset to be private. | ・すべてのオブジェクト・ストレージを非公開にする。オブジェクト・ストレージをすべてプライベートに保つ。オブジェクト・ストレージが公開を意図していない場合や,公開を想定していないデータを含んでいる場合は,ストレージ資産の設定をプライベートに変更することがベストプラクティスである。 |
| · Use a secure sharing process. If the data needs to be shared with external parties, solutions such as a pre-signed URL, AWS STS or Azure SAS for providing temporary access. | ・安全な共有プロセスを使用する。データを外部と共有する必要がある場合は,事前に署名されたURL,AWS STS,Azure SASなどの一時的なアクセスを提供するソリューションを利用する。 |
| · Network security controls. Keep all networks to the object storage within your private subnets and the CSP backbone instead of traversing over the public Internet, using services such as private endpoints. | ・ネットワークのセキュリティ管理。オブジェクト・ストレージへのネットワークはすべて,プライベート・エンドポイントなどのサービスを利用し,パブリック・インターネットを経由せず,プライベート・サブネットとCSPバックボーン内で管理する。 |
| · Use encryption keys. Ensure all object storage resources are encrypted in transit and at rest. Prefer to use customer-managed encryption keys and rotate the keys according to predefined policy (at least once a year). Manage access to the encryption keys using the CSP identity and access management mechanism. | ・暗号鍵を使用する。すべてのオブジェクト・ストレージ・リソースが転送中および静止時に暗号化されていることを確認する。顧客が管理する暗号鍵を使用し、事前に定義したポリシーに従って鍵をローテートすることを推奨する（少なくとも年に1回）。CSP の ID およびアクセス管理メカニズムを使用して、暗号化鍵へのアクセスを管理する。 |
| · Avoid using basic or no-authentication. While additional resources and services may be required, it is recommended to use a cloud-native IAM-based authentication or another open standard such as SAML, OIDC, etc. | ・基本認証または本人認証なしの使用は避ける。追加のリソースやサービスが必要になる場合もあるが,クラウド・ネイティブな IAM ベースの認証,または SAML,OIDC などの別のオープン標準を使用することを推奨する。 |
| · Ensure a thorough understanding of the shared responsibility model - This involves understanding the division of security responsibilities between the cloud service provider and the organization using the cloud service, and identifying which security measures are the responsibility of each party. By understanding this model and implementing the appropriate security measures, organizations can help ensure the security of their object storage in the cloud. | ・責任共有モデルの徹底的な理解 ・これには,クラウド・サービス・プロバイダとクラウド・サービスを利用する組織の間のセキュリティ責任の分担を理解し,どのセキュリティ対策が各当事者の責任であるかを特定することが含まれる。このモデルを理解し,適切なセキュリティ対策を実施することで,組織はクラウド上のオブジェクト・ストレージのセキュリティを確保することができる。 |
| 6: Third-Party Cross-Environment/ Account Access | 6: サードパーティによるクロス環境/アカウントアクセス |
| Definition | 定義 |
| This attack vector details the trust given to a third-party entity or resource to access the customer’s cloud environment. In this attack vector, the permissions given are overly permissive and can lead to account takeover from the third-party company. In some cases, the granted permissions are not powerful enough but might be abused in order to gain additional permissions or identities which can lead to account takeover. | この攻撃ベクトルでは、顧客のクラウド環境にアクセスするためにサードパーティーの事業体やリソースに与えられる信頼について詳述する。この攻撃ベクトルでは、与えられたパーミッションが過度に寛容であり、サードパーティ企業からのアカウント乗っ取りにつながる可能性がある。場合によっては、付与されたパーミッションが十分に強力ではなく、アカウントの乗っ取りにつながる追加的なパーミッションやIDを得るために悪用される可能性がある。 |
| Description | 説明 |
| Organizations may rely on third-party vendors and managed service providers to support, monitor, or secure their environment. There are multiple ways for this access to take place: by API, IAM Role, VPC peering, agent software, or specific VM or container that is residing in the customer environment but controlled by a third party. If the third party is compromised, it exposes the company to certain risks. | 組織は、サードパーティ・ベンダーやマネージド・セキュリティ・サービス・プロバイダに、その環境のサポート、監視、セキュリティ確保を依存している場合がある。このアクセスには、API、IAMロール、VPCピアリング、エージェント・ソフトウェア、あるいは顧客環境に存在するがサードパーティが管理する特定のVMやコンテナなど、複数の方法がある。サードパーティが侵害された場合、企業は特定のリスクにさらされることになる。 |
| Key Takeaways | 要点 |
| · Choose your third-party providers wisely, after executing a detailed security assessment making sure the vendors are in the required security level | ・詳細なセキュリティ・アセスメントを実施し,ベンダーが必要なセキュリティ・レベルにあることを確認した上で,サードパーティ・プロバイダを賢く選択する。 |
| · Follow the principle of least privilege by providing minimum required permissions, and have a process in place to review and reduce permissions | ・最小権限の原則に従い,必要最小限の権限を提供し,権限を見直し,削減するプロセスを導入する。 |
| · If possible (per Legal department approval) delete every identity and third-party accounts once they are not in use | ・可能であれば(法務部門の承認に基づき),すべての ID とサードパーティのア カウントが使用されなくなったら削除する。 |
| · Ensure MFA is configured for external users | ・外部ユーザに対して MFA が設定されていることを確認する。 |
| · Use technologies such as AWS STS, Azure Privileged Identity Management or Azure Just-in-Time access for providing access to external support services | ・外部サポートサービスへのアクセスを提供するために,AWS STS,Azure Privileged Identity Management,または Azure Just-in-Time アクセスなどのテクノロジを使用する。 |
| · Audit all actions done by all identities and make sure there are logging mechanisms in place to detect anomalous behavior | ・すべての ID で実行されるすべてのアクションを検知し,異常な動作を検知するためのロギングメカニズ ムがあることを確認する。 |
| · Ensure security mechanisms are in place to prevent unauthorized log in activities, for example, external ID for assuming IAM roles | ・例えば,IAM ロールを引き受けるための外部 ID などである。 |
| · Periodically map the shared resources, and analyze the risk and the derived meanings. | ・共有リソースを定期的にマッピングし,リスクと導き出された意味を分析する。 |
| 7: Unsecured/Unencrypted Snapshots & Backups | 7: 安全でない/暗号化されていないスナップショットとバックアップ |
| Definition | 定義 |
| This attack vector refers to the presence of unsecured or unencrypted snapshots or backups on a cloud platform or service. These snapshots/backups may contain sensitive information, such as passwords, personal data, or confidential business information. They can be accessed by unauthorized parties if not properly secured with encryption or other security measures. Properly secured, for this matter, means the same level of the original data is secured. | この攻撃ベクトルは、クラウドプラットフォームやサービス上に安全でない、あるいは暗号化されていないスナップショットやバックアップが存在することを指す。これらのスナップショットやバックアップには、パスワード、個人データ、ビジネス上の機密情報などの機密情報が含まれている可能性がある。暗号化やその他のセキュリティ対策で適切に保護されていない場合、不正アクセスされる可能性がある。ここでいう適切なセキュリティとは、元のデータと同レベルのセキュリティが確保されていることを意味する。 |
| These snapshots/backups can be stored in various locations, and be used to restore data in the event of data loss or other disruptions, so having access to it and maintaining the level of integrity are also important. | これらのスナップショット／バックアップは様々な場所に保存され、データ損失やその他の障害発生時にデータを復元するために使用される可能性があるため、アクセスできることと完全性のレベルを維持することも重要である。 |
| This document will use the phrase “unsecured backup” as an unsecured or unencrypted snapshot or backup. | 本書では、安全でない、あるいは暗号化されていないスナップショットやバックアップとして「安全でないバックアップ」という表現を使用する。 |
| Description | 説明 |
| Several potential vector attacks are using unsecured cloud backups, including: | 安全でないクラウドバックアップを利用した攻撃には、以下のような潜在的なベクトルがある： |
| 1. Elevation of privileges: Attackers may use unsecured backups to move laterally or gain excessive permissions (using the backup to locate keys and passwords). | 1. 権限の昇格： 1.特権の昇格：攻撃者は安全でないバックアップを使用して、横方向に移動したり、過剰な権限を獲得したりする（バックアップを使用してキーやパスワードを見つける）。 |
| 2. Enhancement to ransomware: Attackers may delete unsecured backups to prevent the organization from recovering from a ransomware attack. | 2. ランサムウェアの強化： 攻撃者は、ランサムウェア攻撃から組織が回復するのを防ぐために、保護されていないバックアップを削除する可能性がある。 |
| 3. Misconfigured permissions: If backups are not properly configured with the appropriate permissions, they may be accessible to unauthorized parties, who can then access and manipulate sensitive data. | 3. 権限の設定ミス： バックアップが適切な権限で適切に設定されていない場合、無許可の第三者がアクセスできるようになり、機密データにアクセスして操作される可能性がある。 |
| 4. Malicious code injection: Attackers may use unsecured backups as a means of injecting malicious code into systems or networks, which can result in data loss, system disruption, and other negative impacts. | 4. 悪意のあるコードインジェクション： 攻撃者は、システムまたはネットワークに悪意のあるコードを注入する手段として、保護されていないバックアップを使用する可能性がある。 |
| Key Takeaways | 要点 |
| Here are several recommendations, and best practices for preventing potential vector attacks using unsecured backups as follows: | 以下は、保護されていないバックアップを使用した潜在的なベクター攻撃を防ぐためのいくつかの推奨事項とベストプラクティスである： |
| · Apply data minimization (via data retention policy) also on your cloud backup, removing unnecessary information, thus reducing the risk. | ・クラウドバックアップにも（データ保持ポリシーによる）データ最小化を適用し、不要な情報を削除することで、リスクを低減する。 |
| · Use strong, unique passwords for all cloud backup accounts and regularly update them to prevent unauthorized access. | ・すべてのクラウドバックアップアカウントに強固でユニークなパスワードを使用し,不正アクセスを防ぐために定期的に更新する。 |
| · Enable MFA for cloud backup human accounts and restrict access of service accounts to known traffic sources, to add an extra layer of security. | ・クラウドバックアップのヒューマンアカウントにMFAを有効にし,サービスアカウントへのアクセスを既知のトラフィックソースに制限し,セキュリティのレイヤーを追加する。 |
| · Use encryption for all cloud backups and snapshots to protect sensitive data from being accessed by unauthorized parties | ・すべてのクラウドバックアップとスナップショットに暗号化を使用し,機密データを不正アクセスから保護する。 |
| · Use customer-managed encryption keys, and store them in a secured vault (such as AWS KMS, Azure Key Vault, or Google Cloud KMS). | ・顧客が管理する暗号鍵を使用し、安全な保管庫（AWS KMS、Azure Key Vault、Google Cloud KMSなど）に保管する。 |
| · Quarterly review and update permissions for all cloud backups and snapshots to ensure that only authorized identities can access them. | ・すべてのクラウドバックアップとスナップショットのアクセス許可を四半期ごとに見直し,更新し,許可されたIDのみがアクセスできるようにする。 |
| · Implement a backup and recovery plan to ensure that data is properly backed up and easily restored during data loss or other disruptions. | ・バックアップと復旧計画を実施し,データが適切にバックアップされ,データ損失やその他の障害時に容易に復旧できるようにする。 |
| · Regularly review and update security measures to ensure they effectively protect against potential threats to the backups and snapshots. | ・バックアップとスナップショットに対する潜在的な脅威から効果的に保護するために,セキュリティ対策を定期的に見直し,更新する。 |
| · Keep backups and snapshots in an archive tier or another cloud provider, with proper access management, store them in immutable form, and monitor any access to them. | ・バックアップとスナップショットは,適切なアクセス管理のもと,アーカイブ階層または別のクラウドプロバイダに保管し,不変の形式で保存し,それらへのアクセスを監視する。 |
| 8: Compromised Images | 8: 危殆化したイメージ |
| Definition | 定義 |
| Images are files (or sets of files) that provide the initial installation files for a workload. This vector describes images that have been maliciously modified to exploit vulnerabilities and allow attackers to gain access to cloud resources. This is usually done by creating a back-door in the image or obfuscating malware inside the image. | イメージとは、ワークロードの初期インストールファイルを提供するファイル（またはファイル群）である。このベクターは、脆弱性を悪用し、攻撃者がクラウドリソースにアクセスできるように悪意を持って変更されたイメージを記述する。これは通常、イメージ内にバックドアを作成するか、イメージ内にマルウェアを難読化することで行われる。 |
| Description | 説明 |
| It is important for cloud users to understand the potential risks associated with VM/Container images and to take precautions against cloud attacks originating from compromised VM/Container images. Images that have been compromised can be used to launch cloud-based attacks, such as cloud malware injection, mining cryptocurrency, data exfiltration, or account takeover. | クラウドユーザにとって、VM/コンテナイメージに関連する潜在的なリスクを理解し、侵害されたVM/コンテナイメージを起点とするクラウド攻撃に対して予防策を講じることは重要である。侵害されたイメージは、クラウドマルウェアのインジェクション、暗号通貨のマイニング、データの流出、アカウントの乗っ取りなど、クラウドベースの攻撃を仕掛けるために使用される可能性がある。 |
| The source of the compromised images can be internal, images that were created by the cloud customer from untrusted sources or accessed later on by a malicious threat actor; or external, malicious images that came from image stores, public image repositories, or even from the official marketplace that due to lack of governance allowed the malicious content to be distributed. | 侵害されたイメージのソースには、クラウド利用者が信頼できないソースから作成したイメージや、悪意のある脅威行為者が後からアクセスした内部的なものと、イメージストアやパブリックイメージリポジトリ、あるいはガバナンスの欠如により悪意のあるコンテンツの配布を許可した公式マーケットプレイスから入手した外部的なものがある。 |
| Key Takeaways | 要点 |
| Safeguards against compromised VM/Container images include using images from trusted sources only, monitoring the access to the image store and verifying image integrity, alerting for changes or modifications, ensuring VM/Container images are up-to-date with the most recent security patches, and performing regular scans of VM/Container images. In addition, cloud administrators should implement policy regarding the usage of open source software and images, design access control policies and use cloud-agnostic cloud management tools to manage cloud deployments. By taking these additional precautions, cloud administrators can protect deployments from attack vectors like compromised images. In addition, cloud security administrators should consider implementing cloud-native container security solutions to bolster protections against compromised images and other cloud attack vectors. Kubernetes network security policies, cloud-native security solutions, and cloud application firewalls can further strengthen cloud security. Utilizing cloud security tools allows administrators to respond quickly to any risks or threats to the cloud by detecting malicious activity linked to compromised images. | 侵害されたVM/コンテナ・イメージに対する安全策には、信頼できるソースからのイメージのみを使用すること、イメージストアへのアクセスを監視してイメージの完全性を確認すること、変更や修正を警告すること、VM/コンテナ・イメージを最新のセキュリティパッチで確実に更新すること、VM/コンテナ・イメージを定期的にスキャンすることなどが含まれる。さらにクラウド管理者は、オープンソースソフトウェアやイメージの使用に関するポリシーを導入し、アクセス制御ポリシーを設計し、クラウドにとらわれないクラウド管理ツールを使用してクラウドのデプロイメントを管理する必要がある。このような追加的な予防策を講じることで、クラウド管理者は、侵害されたイメージのような攻撃ベクトルからデプロイメントを保護することができる。さらに、クラウドセキュリティ管理者は、侵害されたイメージやその他のクラウド攻撃ベクトルに対する防御を強化するために、クラウドネイティブなコンテナセキュリティソリューションの実装を検討すべきである。Kubernetesのネットワーク・セキュリティ・ポリシー、クラウドネイティブ・セキュリティ・ソリューション、クラウド・アプリケーション・ファイアウォールは、クラウドセキュリティをさらに強化することができる。クラウドセキュリティツールを活用することで、管理者は侵害されたイメージに関連する悪意のある活動を検知し、クラウドに対するリスクや脅威に迅速に対応することができる。 |
Comments