Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2023年1月24日にNIGEL DOUGLAS が投稿したブログ（https://sysdig.com/blog/how-to-prevent-ddos-attack-cloud)を元に日本語に翻訳・再構成した内容となっております。
クラウド環境におけるDDoS攻撃を防ぐために、この（DDoS攻撃の）脅威に関連する侵害の兆候を早期に検出する方法を学びたいのであれば、この記事は、クラウド・インフラストラクチャを保護するために必要なベストプラクティスの大半を説明しています。
2022年1月から7月にかけて、Sysdig脅威リサーチチームはグローバルハニーネットシステムを導入し、複数の攻撃ベクトルによる多数の侵害をキャプチャーしました。2022版クラウドネイティブな脅威に関するレポート（日本語版）で2021年第4四半期と2022年第1四半期の攻撃タイプを比較すると、クリプトマイニングからDDoS（分散サービス妨害）活動へと明らかにシフトしています。
攻撃タイプの経時的な比率（2021年第4四半期）
攻撃タイプの経時的な比率（2022年第1四半期）
前回は、KubernetesにおけるDoS攻撃を軽減するために、CalicoやFalcoなどのオープンソースツールを用いて、DoS防御やランタイム時のDoS検知を行う方法について解説しました。次の記事では、特にクラウド環境 - AWS、Azure、GCPなど - におけるDoS攻撃の緩和方法について説明することを目的としています。
DDoS攻撃のパターンと動作は、OSIモデル内の異なるレイヤーに分離することができます。
このブログ記事では、CNCFプロジェクトFalcoを使用して、クラウドでのDoS攻撃につながるIndicators of Compromise（IoC）を検出することを目的としています。これを達成するために、Falcoは様々なクラウドプロバイダーの監査ロギングサービスにプラグインする必要があります。ありがたいことに、Falcoは各クラウドデータソースのための専用プラグインを提供しています。
予想されるネットワークトラフィック/挙動を時系列で監視することで、実行時に異常なネットワーク挙動を検出するためのFalcoのルールを設計することができます。
出発点として、お客様のウェブサーバーがブルートフォース攻撃から保護されていることを確認することが重要です。攻撃者は、サーバーへのアクセスを取得したり、一時的にサーバーを応答不能にすることを目的としています。ブルートフォース攻撃では、正しいパスワードが見つかるまで、何千、何百万ものパスワードを試行します。
一方、エンドユーザーは、この種の攻撃が成功しないように、強力なパスワードを生成する際にセキュリティポリシーに従わなければななりません。また、ほとんどのクラウドプロバイダーは、ブルートフォース攻撃を防ぐために、レートリミットのようなツールを提供しています。
脅威を検知する主なソリューションの1つは、アプリケーションのログインページで、漏洩した認証情報を使用してユーザーアカウントに不正アクセスされていないか監視することです。アカウント乗っ取りは、攻撃者が人のアカウントに不正にアクセスするオンラインの違法行為です。
AWSのWAFテクノロジーの場合、潜在的な不正アクセスを検知するATP（Account Takeover Prevention）機能を備えています。これは、DoS攻撃につながる可能性のある最も明確なIoCです。
攻撃者は、盗んだ認証情報を使用したり、一連の試行を通じて被害者のパスワードを推測するなど、さまざまな方法でエンドユーザーのアカウントにアクセスすることができます。Falcoは、各クラウドプロバイダー（GCP、AWS、Azureなど）のクラウド監査ロギングサービスにプラグインしているので、例えば、通常とは異なるIPからのAWSアカウントログインを検出するFalcoのルールを作成することができます：
- rule: Console Login Success From Untrusted IP
desc: Detect a console login success from an untrusted IP address
condition: >-
aws.eventName="ConsoleLogin" and
jevt.value[/responseElements/ConsoleLogin]="Success" and not aws.sourceIP in
(trusted_ip_addresses)
output: >-
Detected a console login success from an untrusted IP address (requesting
user=%aws.user, requesting IP=%aws.sourceIP, AWS region=%aws.region,
arn=%jevt.value[/userIdentity/arn], user agent=%jevt.value[/userAgent])
priority: info
source: aws_cloudtrail
ユーザーが「ログインすべき」IPアドレスが分かっている場合、それらをtrusted_ip_addressesリストに追加することができます。そうすれば、潜在的に悪意のあるユーザーがエンドユーザーの認証情報にアクセスし、クラウド環境にアクセスしようとした場合、不明なIPから環境にアクセスしたことが通知されるようになります。
このようなリアルタイムのアラートを受けて、アカウントにMFAを適用したり、ユーザーが正規にアクセスしたかどうかが分かるまでアカウントを一時的に停止したりするなど、プロアクティブなアクションを適用することが可能です。ユーザーがMFAを使わずにログインに成功した場合、以下のルールをトリガーします。
- rule: Console Login Without MFA
desc: Detects a console login without MFA.
condition: >-
aws.eventName="ConsoleLogin" and not aws.errorCode exists and
jevt.value[/userIdentity/type]!="AssumedRole" and
jevt.value[/responseElements/ConsoleLogin]="Success" and
jevt.value[/additionalEventData/MFAUsed]="No"
output: >-
Detected a console login without MFA (requesting user=%aws.user, requesting
IP=%aws.sourceIP, AWS region=%aws.region)
priority: critical
source: aws_cloudtrail
私たちの最も強い推奨事項の1つであるMFAをすでに組織内で実施している場合（セキュリティの別のレイヤーを追加する）、あなたは正しい決断をしています。
しかし、インサイダー脅威や、MFAスパミングによってアクセス権を得た高度な脅威行為者は、完全な権限を持つ新しいIAMユーザーを作成する際に、検出を回避するためにMFAを無効にすることを検討する可能性があるのです。IAMグループのMFAが無効化または削除されたときに検出することで、プラットフォームチームがクラウドプロバイダーへの安全でないログインを防止することができます。
- rule: Azure Deactivate MFA for User Access
desc: >
Multi-factor authentication requires an individual to present a minimum of
two separate forms of authentication before access is granted. Multi-factor
authentication provides additional assurance that the individual attempting
to gain access is who they claim to be. With multi-factor authentication, an
attacker would need to compromise at least two different authentication
mechanisms, increasing the difficulty of compromise and thus reducing the risk.
condition: >-
jevt.value[/operationName]="Disable Strong Authentication" and
jevt.value[/properties/result]="success"
output: >-
Multi-factor authentication configuration has been disabled for a user
(requesting user=%jevt.value[/properties/initiatedBy/user/userPrincipalName],
requesting IP=%jevt.value[/properties/initiatedBy/user/ipAddress],
target user=%jevt.value[/properties/targetResources/0/userPrincipalName])
priority: warning
source: azure_platformlogs
すべてのクラウドプロバイダーには、アクセスコントロールリスト（ACL）に似た機能があります。ACLは、サブネットレベル（OSIのレイヤー3およびレイヤー4）で特定のインバウンドまたはアウトバウンドトラフィックを許可または拒否するものです。VPCにセキュリティのレイヤーを追加するために、セキュリティ・グループのルールと同様のルールでVPC用のカスタム・ネットワークACLを作成することができます。
残念ながら、一部の組織では、これらの ACL を公共のインターネットに公開しています。
その結果、これらの過度に寛容な ACL により、クラウド環境が外部の敵対者からプローブされる可能性があります。クラウド環境をエアギャップすることで、外部からのプローブを防ぐことができますが、多くのアプリケーションはパブリック・インターネットに開放する必要があります。
そのため、特にこれが必ずしも必要でない場合は、ACLがパブリックアクセスで作成されたときに検出するためにFalcoを使用することが重要です：
- rule: Create a Network ACL Entry Allowing Ingress Open to the World
desc: >-
Detects Access Control List creation allowing ingress open to the world
condition: |
aws.eventName="CreateNetworkAclEntry" and not aws.errorCode exists and (
not (
jevt.value[/requestParameters/portRange/from]=80 and
jevt.value[/requestParameters/portRange/to]=80
) and
not (
jevt.value[/requestParameters/portRange/from]=443 and
jevt.value[/requestParameters/portRange/to]=443
) and
(
jevt.value[/requestParameters/cidrBlock]="0.0.0.0/0" or
jevt.value[/requestParameters/ipv6CidrBlock]="::/0"
) and
jevt.value[/requestParameters/egress]="false" and
jevt.value[/requestParameters/ruleAction]="allow"
)
output: >-
Detected creation of ACL entry allowing ingress open to the world
(requesting user=%aws.user, requesting IP=%aws.sourceIP, AWS
region=%aws.region, arn=%jevt.value[/userIdentity/arn], network acl
id=%jevt.value[/requestParameters/networkAclId], rule
number=%jevt.value[/requestParameters/ruleNumber], from
port=%jevt.value[/requestParameters/portRange/from], to
port=%jevt.value[/requestParameters/portRange/to])
priority: error
source: aws_cloudtrail
ACLは、State-Exhaustion攻撃を防御するのに役立ちます。ネットワーキング層（レイヤー4）では、攻撃者はSYNフラッディングを実現しようとします。SYNフラッドはサービス拒否の一種で、攻撃者が接続を確定させずにサーバーへの接続を急速に開始します。サーバーはその後、（TCPハンドシェイクのワークフローの一部として）半開きの接続を待つために過剰なリソースを費やす必要があり、システムが正当なイングレストラフィックに反応しないようにするために必要な相当量のリソースを消費します。
SYNフラッディングは、ルーター、ファイアウォール、イングレスコントローラー、ロードバランサー、Apacheなどのアプリケーションサーバーなど、ほとんどのネットワーク／セキュリティデバイスに存在するTCP接続状態テーブルを消費します。ネットワークへのアクセスをロックダウンすることで、このようなDynの攻撃を防ぐことができます。
ウェブアプリケーションファイアウォール（WAF）でアプリケーション（レイヤー7）のDDoS防御を設定する。これは、クラウドプロバイダーが提供するWAF技術で実現することも、サードパーティーベンダーを経由して実現することもできます。
AWSクラウドの場合、独自のWAF機能を提供しています。これは L7 リソースに転送される HTTP と HTTPS のリクエストを監視し、それらのリクエストの特性に基づいてコンテンツへのアクセスを制御することができます。ACL を利用して、単一の IP アドレスからのトラフィック量に対してレートベースのルール制 限を適用します。これらは、アプリケーションに対するDDoS防御の要件となります。
画像はAWS WAFの公式ページより引用
上記のACLの項で紹介したSYNフラッディングと同様に、HTTP/SフラッディングもDoSを引き起こすための一般的な攻撃手法です。これは、HTTP GETまたはPOSTアクティビティで構成されるDNSクエリをアプリケーション層に殺到させることで発生します。その目的は、メモリ、CPU、帯域幅など、アプリケーションのリソースを過剰に消費させることです。
攻撃者の視点から見ると、被害者のインフラストラクチャーのどこに欠陥があるのかを知る必要があります。これらのリクエストは、データベースやアプリケーションの処理に遅延を生じさせるでしょうか？
もしそうなら、基盤となるウェブサービスは悪意のあるリクエストに阻まれ、サービスを利用しようとする他のユーザーにサービスを提供することができないはずです。L7 型の攻撃と同様に、悪意のあるトラフィックと予想される通常のトラフィックの違いを知ることは、脅威を軽減するために不可欠です。
このシナリオでは、クラウド環境内のVM/EC2インスタンスにFalcoをインストールすることができます。
ホストからのシステムコールに基づき、アプリケーションレベルのトラフィックアクティビティを確認することができます。Falcoでは、信頼できるドメイン名（sysdig.com、github.com、google.com）のリストを定義するオプションがあります。これらのドメイン名のいずれかによって解決されないIPアドレスへのネットワーク接続は、ポリシーをトリガーします。
- list: trusted_domains
items: [sysdig.com, github.com, google.com]
- rule: Unexpected outbound network connection
desc: Detect outbound connections with destinations not on allowed list
condition: >
Outbound
and not (fd.sip.name in (trusted_domains))
output: Unexpected Outbound Connection
(container=%container.name
command=%proc.cmdline
procpname=%proc.pname
connection=%fd.name
servername=%fd.sip.name
serverip=%fd.sip
type=%fd.type
typechar=%fd.typechar
fdlocal=%fd.lip
fdremote=%fd.rip)
priority: NOTICE
WAFルールを作成し、HTTPヘッダー、HTTPボディ、お客様のURIなどの条件に基づいて、Webリクエストをフィルタリングします。
同様に、ACLルールを使用して、IPアドレスに基づくWebトラフィックをフィルタリングします。ACLの安全でない設定（公衆インターネットに公開されている）を検出するためにFalcoを使用するのと同様に、ボットネット活動にしばしば関連するC2サーバーに向かう接続を検出するためにFalcoのルールを使用することができます。
- list: c2_server_ip_list
items: [1.234.21.73, 100.16.107.117, 100.6.8.7]
- rule: Outbound Connection to C2 Servers
desc: Detect outbound connection to command & control servers
condition: outbound and fd.sip in (c2_server_ip_list)
output: Outbound connection to C2 server (command=%proc.cmdline pid=%proc.pid connection=%fd.name user=%user.name user_loginuid=%user.loginuid container_id=%container.id image=%container.image.repository)
priority: WARNING
tags: [network]
もちろん、好きな脅威のフィードを使用することができます。c2_server_ip_listは、Feodo Tracker C2 IP Blocklist内の最初の3つのIPアドレスに基づいて作成しました。
Abuse.chのチームは、これらのIPをフィルタリングして、トロイの木馬化ローダー、ランサムウェア、サービス拒否などのさまざまな攻撃手法にどのように使用されているかをより理解するためのシンプルなUIを提供しています。
C2サーバーへの疑わしいアウトバウンドトラフィックを検出するのと同様に、私たちはクラウドサービスへの疑わしいインバウンドトラフィックも検出したいと考えています。
- rule: AWS Suspicious IP Inbound Request
desc: >-
Detect inbound requests from known suspicious IP sources, such as TOR exit
nodes, to AWS services.
condition: >-
aws.sourceIP in (ti_anon_ips) and not (aws.eventName="ConsoleLogin" and
jevt.value[/responseElements/ConsoleLogin]="Failure")
output: >-
Suspicious IP Inbound Request (aws.sourceIP=%aws.sourceIP,
aws.region=%aws.region, aws.eventName=%aws.eventName, aws.user=%aws.user,
userAgent=%jevt.value[/userAgent], errorMessage=%jevt.value[/errorMessage])
priority: warning
Tags: [Cloud, AWS]
source: aws_cloudtrail
同じFalcoのルールロジックを使って、Torなどのリレーネットワークへの接続をブロックすることができますが、TorはDDoS攻撃を行うための理想的なユースケースではないことに注意することが重要です。
目標は被害者の帯域幅を圧倒することなので、ハンドシェイクや協調を必要としないUDPパケットを送るのが一般的です。ホストとワークロードのレベルでは、標準的なポート 53 のトラフィックから逸脱した不審な UDP トラフィックを Falco で検出することができます。
- rule: Unexpected UDP Traffic
desc: UDP traffic not on port 53 (DNS) or other commonly used ports
condition: >-
(inbound_outbound) and do_unexpected_udp_check and fd.l4proto=udp and not
Expected_udp_traffic
output: >
Unexpected UDP Traffic Seen (user.name=%user.name
user.loginuid=%user.loginuid proc.cmdline=%proc.cmdline connection=%fd.name
proto=%fd.l4proto evt.type=%evt.type %evt.args container.id=%container.id
evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid
proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath
user.uid=%user.uid user.loginname=%user.loginname group.gid=%group.gid
group.name=%group.name container.name=%container.name
image=%container.image.repository)
priority: notice
source: syscall
しかし、TorはすべてのIPパケットではなく、正しく形成されたTCPストリームのみを転送するので、Tor上でUDPパケットを送ることはできません（SYNフラッディングのようなこの攻撃の特殊な形式もできません）。
そのため、一般的に、効果的なDDoS攻撃を行うのに十分な帯域幅を制御している攻撃者は、Torなしでも十分にそれを行うことができます。とはいえ、Torは攻撃者が何らかの形で匿名性を維持できるため、DDoS攻撃の前にデータを漏洩させるのに有効です。もっと知りたい方は、Torネットワーク接続を検出する方法の記事をご覧ください。
利用するクラウドプロバイダーによっては、独自の脅威フィードをプラグインして、既知の悪質なコマンド＆コントロール（C2）ボットネットサーバーからの接続かどうかを判断し、これらの攻撃をブロックするルールが提供されることがよくあります。しかし、ホストのシステムコールレベルで潜在的に悪意のある接続や偵察スクリプトを検出するために、Falcoのようなオープンソースツールがあるのは良いことです。
- rule: Detect reconnaissance scripts
desc: This rule detects the use of reconnaissance scripts.
condition: evt.type=execve and reconnaissance_scripts
output: >-
Detected reconnaissance script executing (proc.cmdline=%proc.cmdline
container=%container.info evt.type=%evt.type
evt.arg.request=%evt.arg.request proc.pid=%proc.pid proc.cwd=%proc.cwd
proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid
proc.exepath=%proc.exepath user.uid=%user.uid user.loginuid=%user.loginuid
user.loginname=%user.loginname user.name=%user.name group.gid=%group.gid
group.name=%group.name container.id=%container.id
container.name=%container.name image=%container.image.repository)
priority: warning
source: syscall
すべての L7 WAF 技術は、クラウド環境の開発と設計のプロセスに組み込むことができ、ある種の API セキュリティを提供する必要があります。
API は、ユーザーとのインタラクションを生成するための関連コマンド、ペイロード、およびデータのすべてをパッケージ化しているため、開発者にとって理想的なものです。しかし残念なことに、このコンテキストとインタラクティビティのすべてが、セキュリティ・リスクを生み出します。企業がAPIの利用を拡大し続けることで、未知の攻撃対象が増加します。
多くの企業はAPIをシャドーイングしておらず、APIを隠す方法や、特定のAPIが非推奨かどうかを確認する知識もありません。どれがサードパーティ製で、どれがサポートされなくなったかを知らなければ、これらのAPIの多くを保護されないままにしておく危険性があります。
残念ながら、WAF は API を保護するために必要な可視化インベントリ追跡、リスク評価、およ び脅威防御の要件に対応していません。
Falcoでは、API キーがいつ作成されたかを検出することができ、それが誰によって作成さ れたか、いつ作成されたか、キー ID がどのプロジェクトに関連するかを確認するための全体的な監 査に役立てることができます。
- rule: GCP Create API Keys for a Project
desc: Detects the creation of API keys for a project.
condition: >-
gcp.serviceName="apikeys.googleapis.com" and gcp.methodName endswith
".ApiKeys.CreateApiKey"
output: >-
An API key for a project has been created (requesting user=%gcp.user,
requesting IP=%gcp.callerIP, project
id=%jevt.value[/protoPayload/request/projectId], key
id=%jevt.value[/protoPayload/response/keyId])
priority: warning
source: gcp_auditlog
append: false
exceptions: []
GKE、EKS、AKSなどのマネージドクラウドKubernetesサービスで稼働するクラウドネイティブなコンテナ型ワークロードに関して、FalcoコンテナがKubernetes APIサーバーと通信できるタイミングを検出することができます。こうすることで、K8sレベルで異常な/予期しないDoS活動を検出することができます。
- rule: Contact K8S API Server From Container
desc: Detect attempts to contact the K8S API Server from a container
condition: >
evt.type=connect and evt.dir=< and
(fd.typechar=4 or fd.typechar=6) and
container and
not k8s_containers and
k8s_api_server and
not user_known_contact_k8s_api_server_activities
output: Unexpected connection to K8s API Server from container (command=%proc.cmdline pid=%proc.pid %container.info image=%container.image.repository:%container.image.tag connection=%fd.name)
priority: NOTICE
tags: [network, k8s, container, mitre_discovery]
KubernetesのAPIレベルで異常なDoS活動を検出することが、Kubesharkによってさらに容易になりました。
Kubesharkユーティリティは、Kubernetesクラスター内のコンテナやPodに出入りするすべてのAPIトラフィックとペイロードの深い可視化と監視を提供します。これらのクラウドネイティブなワークロードは、しばしばそれらが常駐するクラウドサービスにまで拡張されます。
Kubesharkは、APIトラフィックから推測される自動生成されたAPIとサービスインベントリを提供することで支援します。そうすれば、すべてのAPIトラフィックとペイロードを（ライブであれ履歴であれ）監視し、APIドリフトとAPIアノマリーを見つけることができます。これらをソースまで追跡することができるようになります。
Kubernetes を使用しているかどうかに関わらず、クラウド上のすべての組織は POST/GET アクティビティを自動的に追跡し、正当/不正なエンドポイントや宛先アドレスにする必要があります。社内のAPIリスク評価、または前述のようなサードパーティソフトウェアを使用して、継続的にAPIの発見と可視化を実行することをお勧めします。クラウドプロバイダーはAPI脅威の検知機能を提供し、これらの脅威をリアルタイムでネイティブに軽減することができるでしょうか？
例えばAWS GuardDutyは、DNS、TCP、UDP、UDP on TCPポート、および一般的でないプロトコルアクティビティに対するDoSアクティビティを検出することができます。
要約すると、今後クラウドでのDDoS攻撃を防ぐためには、アプリケーション層とネットワーク層の両方に適用される特定の緩和戦略を適用する必要があるということです。
クラウドでの DDoS 攻撃を防止するために、いくつかの手順を実行することができます：
ファイアウォールやその他のネットワークセキュリティツールを使用する。
CDNは、複数のサーバーにトラフィックを分散させることができるため、DDoS攻撃によるネットワークへの侵入をより困難にすることができます。
特定のソースからのトラフィックが突然増加するなど、通常とは異なるトラフィックパターンがないか、定期的にネットワークを監視します。これは、DDoS攻撃を示唆している可能性があります。
多くのクラウドプロバイダーは、デフォルトでビルトインのアカウント乗っ取りおよび緩和機能を提供しています。MFAは、盗まれた認証情報でコンソールにアクセスする際に、セキュリティの層を厚くします。前述のとおり、クラウドインフラクチャーに対して不正なパスワードの試行回数を制限するには、レートリミッティングが有効です。
クラウドベースのDDoS保護サービスはいくつかあり、DDoS攻撃がネットワークに到達する前に吸収し、軽減するのに役立ちます。
DDoS攻撃への対応について、誰に連絡するか、どのような手順で攻撃を軽減するかなど、計画を立てておくことが重要です。
これらのステップに従うことで、クラウドベースのシステムとサービスをDDoS攻撃から保護することができます。
クラウドプロバイダーは、お客様をDDoS攻撃から保護するために素晴らしい仕事をしています。実際、今年Google Cloudは、4600万Requests Per Second（RPS）という過去最大のLayer 7 DDoS攻撃をブロックしました。とはいえ、このセキュリティ機能は、すべてのお客様に対してデフォルトで有効になっているわけではありません。標的となった企業は、GoogleのCloud Armorソリューションのライセンスを持つエンドユーザーでした。このお客様は、Cloud Armor のような WAF ソリューションの強力なユースケースである、一連の HTTPS DDoS 攻撃の標的にされていました。
ウクライナ DDoS 攻撃
国家間の戦争の武器となるDDoS攻撃が増加していることを検知しています。特定の政治的イベントに対応してDDoSキャンペーンを成功させるためには、サイバー犯罪者グループはボットネットインフラストラクチャーを迅速にスケールアップする必要があります。
これらのDDoS攻撃は、標的となるものや攻撃者の目的に応じて、市民的、社会的、経済的な損害をもたらす可能性があります。たとえば、紛争が始まった当初、親ロシア派のDDoS攻撃は、ウクライナの金融機関へのアクセスを妨害することができました。
記事で述べたように、クラウドでDoS攻撃を実現する方法は複数存在します。
Volumetric 攻撃（レイヤー3）は、今後もあらゆるWeb向けアプリケーションで最も一般的なアプローチとなるでしょう。UDPリフレクション攻撃などのネットワークフラッディング技術は、TCPハンドシェイクを待つ必要がないと述べたように、攻撃者はUDPやICMPフラッドでアプリケーションにスパムを送ることができるため、理想的な手法と言えます。
時が経つにつれ、より洗練された L7 攻撃（HTTP/DNS フラッドを狙ったものではなく、API を攻撃するもの）が増えてきています。
多くの WAF 技術は、正当な API 接続と不正な API 接続を保護するのに必要な可視性を欠いているため、多くの接続がガードレールなしで通過することになります。開発者のミス、ベストプラクティスの欠如、不適切なトレーニングは、悪意ある者に簡単に利用される脆弱性につながる可能性があります。APIはバックエンドシステムとの高速通信を可能にすることが多く、たとえ完璧にコーディングされていても、自動化された攻撃やビジネスロジックの乱用の格好のターゲットになってしまいます。
というわけで、クラウドにおけるサービス拒否を防御する方法について、ご理解いただけたでしょうか。
すべてのDoS攻撃が同じように生まれているわけではありません。説明したように、攻撃者が選択する新しいDDoS攻撃のベクトルとして、自動化や統合のためにSaaSプラットフォームに不可欠な存在となっているAPIなどがあります。組織の規模に関係なく、基本的なガードレールを適用することが重要です。システムの潜在的な弱点を特定し、脆弱性スキャナを使用して既知のセキュリティ上の欠陥がないかスキャンしましょう。
設定ミスを発見したら、適切な対策と脅威の検知を実施し、セキュリティを確保するための措置を講じましょう。
Sysdig Secureは、クラウドプロバイダー間でのセキュリティ態勢の改善を支援します。Sysdigは、Infrastructure-as-Code（IaC）テンプレート内の脆弱性だけでなく、ランタイム環境内の脆弱性も検出します。Sysdigは、ユーザー認証が侵害された場合の影響範囲を限定するために、最小権限のIAMポリシーを推奨しています。Sysdigは、様々なクラウドプロバイダーのクラウド監査ログに接続することで、Azure、GCP、AWSのテナントにおける脅威の全体像を可視化することが可能です。
