Khóa API, Bí mật AWS hoặc Mã thông báo Stripe Live được cam kết cho GitHub Repo công khai: Quét bot tự động trong 60 giây, Xoay khóa ngay lập tức và Kill-Switch thanh toán¶

Ngay khi bạn chạy git push tới kho lưu trữ GitHub, GitLab hoặc Bitbucket công khai (or temporarily flip a private repository to "Public" for even 10 seconds) trong khi một tập tin, .env cấu hình, sổ ghi chép Jupyter (.ipynb) hoặc lịch sử cam kết Git cũ hơn chứa khóa bí mật trực tiếp (such as an AWS Access Key ID starting with AKIA, a Stripe Live Secret Key sk_live_, an OpenAI key sk-proj-, an Anthropic key sk-ant-, or a Google Cloud service account .json), một mạng lưới toàn cầu gồm các bot thu thập thông tin xác thực tự động sẽ chặn bí mật đó trong 2 đến 60 giây. Bởi vì GitHub công khai Events API, GH Archivevà webhook firehook thời gian thực phát trực tuyến mọi công chúng PushEvent Trên toàn cầu, các bot quét độc hại sẽ phân tích sự khác biệt của bạn bằng các biểu thức thông thường và bắt đầu thực thi các lệnh đám mây tự động trước khi bạn kịp gõ git revert.

Trong 90 seconds của một AWS hoặc GCP bí mật tấn công vào kho lưu trữ công khai, các botnet tự động sẽ tạo ra các phiên bản GPU/CPU có kích thước tối đa (such as p4d.24xlarge or c6i.32xlarge trên các khu vực ít người biết đến như ap-east-1 Hồng Kông, me-south-1 Bahrain, hoặc sa-east-1 Sao Paulo) để khai thác Monero (XMR), yêu cầu Dịch vụ email đơn giản của AWS (SES) tăng hạn ngạch để phát tán thư rác lừa đảo hoặc sao chép thông tin cá nhân của bạn S3 xô và RDS cơ sở dữ liệu, tạo $5,000 to $80,000+ trong hóa đơn điện toán đám mây qua đêm. Tương tự, một thông tin bị rò rỉ OpenAI hoặc Anthropic Khóa API ngay lập tức được đưa vào các thị trường LLM "proxy ngược" ngầm, tiêu tốn hàng nghìn đô la tín dụng mã thông báo mỗi phút, trong khi một khóa bị rò rỉ Stripe khóa bí mật trực tiếp (sk_live_...) cấp cho kẻ tấn công quyền truy cập đọc/ghi đầy đủ theo chương trình để thực hiện các khoản tiền hoàn lại gian lận, xuất khẩu cho khách hàng PIIhoặc kích hoạt các khoản thanh toán Connect trái phép. Nếu kẻ tấn công đang tích cực tống tiền tổ chức của bạn sau khi lấy cắp cơ sở dữ liệu khách hàng bằng khóa bị rò rỉ của bạn, hãy tham khảo ý kiến của cơ quan thực thi pháp luật địa phương và đường dây nóng về sự cố mạng thông qua chúng tôi. số khẩn cấp thư mục ngay lập tức và xem lại các hướng dẫn liên quan của chúng tôi về vô tình làm mất cơ sở dữ liệu sản xuất, đẩy lực git và phân loại rò rỉ bí mật, cơ sở dữ liệu sản xuất bị hủy hoặc nhóm S3 bị xóa mà không có bản sao lưu gần đâyvà công việc từ xa khẩn cấp bảo mật và quyền riêng tư dữ liệu.

Làm điều này ngay bây giờ¶

1. KHÔNG lãng phí 60 giây chạy đầu tiên của bạn git rm .env hoặc git push --force: ĐI TRỰC TIẾP TỚI CONSOLE CỦA NHÀ CUNG CẤP (AWS IAM, Stripe, OpenAI, GCP) VÀ THU HỒI/KHÓA KÍCH HOẠT KEY IN < 30 SECONDS. Xóa tệp trong cam kết Git mới (or even making the GitHub repository Private) không làm gì để ngăn chặn các bot đã lấy khóa của bạn khỏi sự kiện GitHub Events 10 giây trước. Bản thân chìa khóa phải bị hủy tại nguồn trước tiên.
2. Nếu một AWS chìa khóa (AKIA... hoặc ASIA...) bị rò rỉ: Mở AWS IAM -> Users -> Security credentials và nhấp ngay vào Tắt / Xóa trên khóa truy cập, sau đó đính kèm AWSCompromisedKeyQuarantineV2 (or a blanketTừ chối *inline policy) cho người dùng IAM và tăng giá trị của người dùng RevokeOldSessions chính sách để loại bỏ bất kỳ tạm thời STS mã thông báo kẻ tấn công đã đúc (see the exact STS bypass trap below).
3. Nếu một Stripe Khóa bí mật trực tiếp (sk_live_... hoặc rk_live_...) bị rò rỉ: Đi tới dashboard.stripe.com/apikeys, nhấp vào ... -> Cuộn phím và đặt thời hạn của khóa cũ thành "Bây giờ (Immediately)" (NOT "in 24 hours"). Kiểm tra ngay Stripe Dashboard -> Logs và Balance -> Payouts / Refunds đối với các lệnh gọi API trái phép.
4. Nếu một OpenAI, Anthropic, Google Geminihoặc SendGrid / Twilio khóa bị rò rỉ: Xóa khóa API trong bảng điều khiển của nhà cung cấp ngay lập tức và đặt Giới hạn chi tiêu cố định hàng tháng ($0 hoặc giới hạn bình thường của bạn) trong cài đặt Thanh toán để cắt bỏ các yêu cầu phát trực tuyến trên chuyến bay.
5. ** Quét TẤT CẢ các vùng đám mây (especially disabled/opt-in regions) dành cho các phiên bản EC2 giả mạo, chức năng Lambda, tác vụ ECS, bộ chứa S3 và người dùng IAM cửa sau do bot tạo trong khoảng thời gian tiếp xúc 2 phút.** Những kẻ tấn công đặc biệt khởi chạy các phiên bản khai thác tiền điện tử ở những khu vực mà bạn không bao giờ nhấp vào trong bảng điều khiển (like Stockholm eu-north-1, Osaka ap-northeast-3, or Mumbai ap-south-1) và tạo người dùng IAM ẩn thứ hai (or SSH key pair) để chúng có thể ở trong tài khoản của bạn sau khi bạn xóa khóa bị rò rỉ.
6. Chỉ SAU KHI bí mật bị thu hồi và các tài khoản IAM cửa sau bị xóa, hãy xóa cam kết khỏi Git (using git-filter-repo) VÀ liên hệ với bộ phận Hỗ trợ GitHub (or remove cached PR/commit views) để xóa bộ nhớ đệm SHA cam kết lơ lửng, sau đó gửi Yêu cầu miễn trừ rò rỉ thanh toán do tai nạn AWS / GCP nếu bot tiêu tốn một khoản hóa đơn lớn trên đám mây.

Cây quyết định: Phản hồi khẩn cấp 60 giây theo loại bí mật bị rò rỉ¶

Thực hiện theo sơ đồ quy trình ngăn chặn sự cố này để loại bỏ thông tin xác thực bị xâm phạm, sự tồn tại của kẻ tấn công máy chủ và đảo ngược việc thanh toán trên đám mây.

flowchart TD
    A["Bí mật trực tiếp được cam kết công khai GitHub / GitLab Repo (.env, Mã nguồn hoặc Lịch sử git)"] --> B["THỨ HAI 0 ĐẾN 30: KHÔNG chạy git rm Đầu tiên. Mở Bảng điều khiển của nhà cung cấp đám mây/API và thu hồi khóa ngay lập tức"]
    B --> C{"Loại thông tin xác thực trực tiếp nào đã bị lộ?"}
    C -->|"1. Khóa truy cập AWS (AKIA.../ASIA...)"| D["1. Vô hiệu hóa/Xóa khóa trong IAM 2. Đính kèm chính sách 'Từ chối tất cả' nội tuyến cho người dùng (Tiêu diệt mã thông báo STS được đúc) 3. Kiểm tra CloudTrail cho người dùng IAM cửa sau"]
    C -->|"2. Khóa bí mật Stripe Live (sk_live_... / rk_live__...)"| E["1. Roll Key có hết hạn = 'Ngay lập tức' 2. Kiểm tra /v1/refunds, /v1/transfers & Webhook Endpoints 3. Đánh giá mức độ phơi nhiễm PII của khách hàng"]
    C -->|"3. OpenAI (sk-proj-...), Anthropic (sk-ant-...), hoặc Gemini Key"| F["1. Thu hồi khóa trong Bảng điều khiển dành cho nhà phát triển 2. Tạm thời hạ giới hạn thanh toán cứng của tổ chức xuống $0 3. Kiểm tra nhật ký sử dụng để tiêu hao mã thông báo"]
    C -->|"4. URI cơ sở dữ liệu (postgres://, mongodb+srv://) hoặc URL Redis"| G["1. Xoay mật khẩu DB ngay lập tức 2. Chạy pg_terminate_backend() / KILL để loại bỏ các kết nối đang hoạt động 3. Chỉ khóa nhóm bảo mật đối với các IP VPC"]
    D --> H["Chạy Quét điện toán đa khu vực (Chấm dứt Rogue EC2/EKS/SageMaker/Lambda ở tất cả hơn 30 khu vực)"]
    E --> I["Lọc lịch sử Git thông qua 'git filter-repo' + Xóa chế độ xem SHA được lưu trong bộ nhớ đệm của GitHub"]
    F --> I
    G --> I
    H --> J{"Các bot tự động có tính phí trên đám mây từ 1.000 đến 100.000 USD không?"}
    J -->|"CÓ"| K["Mở trường hợp hỗ trợ thanh toán AWS/GCP -> Gửi Kiểm tra bảo mật sau khắc phục + Yêu cầu tha thứ cho hành vi gian lận/rò rỉ hóa đơn một lần"]
    J -->|"KHÔNG"| I

Phần 1: Ma trận điều tra và chuyển đổi giữa các nhà cung cấp (First 5 Minutes)¶

Sử dụng bảng tham chiếu này để xác định nút thu hồi chính xác, hành vi Quét bí mật GitHub tự động và vectơ lưu giữ ẩn cho thông tin xác thực bị rò rỉ của bạn.

Phần 2: Tìm hiểu sâu: Cách đuổi kẻ tấn công khỏi tài khoản AWS của bạn (The 4-Step Cloud Eviction Protocol)¶

Bởi vì bị rò rỉ AWS thông tin xác thực có bán kính bùng nổ tài chính cao nhất (up to $50,000+ per day in EC2/SageMaker/Bedrock bills), bạn phải thực hiện tất cả bốn bước dưới đây bất cứ khi nào AKIA... hoặc ASIA... key truy cập vào kho lưu trữ công cộng:

+-----------------------------------------------------------------------------+
|     ANATOMY OF A 60-SECOND AUTOMATED AWS GITHUB SCRAPER BOT ATTACK          |
+-----------------------------------------------------------------------------+
|                                                                             |
|  [ SEC 00 ] Developer runs 'git push origin main' with .env (AKIA...)       |
|       |                                                                     |
|  [ SEC 04 ] Bot scrapes GitHub Events API Firehose -> Extracts AKIA key     |
|       |                                                                     |
|  [ SEC 06 ] Bot calls 'sts:GetCallerIdentity' & 'sts:GetSessionToken'       |
|       |     (Mints temporary ASIA... token that survives AKIA deletion.)    |
|       v                                                                     |
|  +----+------------------------------------------------------------------+  |
|  | [ SEC 15 TO 90: PARALLEL MULTI-REGION EXPLOITATION ]                  |  |
|  |  1. Persistence: Calls 'iam:CreateUser' / 'iam:CreateAccessKey'       |  |
|  |     (Creates hidden user 'aws-support-backup' with AdministratorAccess)|  |
|  |  2. Compute Abuse: Launches Auto-Scaling Groups of c6i.32xlarge /     |  |
|  |     g5.48xlarge in 12 regions + AWS Bedrock / SageMaker LLM endpoints |  |
|  |  3. Spam Abuse: Calls 'ses:PutAccountSendingAttributes' (50k emails)  |  |
|  |  4. Data Exfiltration: Lists & downloads S3 buckets / RDS snapshots   |  |
|  +-----------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------+

Bước 1: Tiêu diệt cả tĩnh AKIA Chìa khóa VÀ Tất cả được đúc ASIA Mã thông báo phiên¶

Xóa AKIA khóa trong Bảng điều khiển AWS không làm mất hiệu lực tạm thời STS thông tin xác thực đã được cấp bởi sts:GetSessionToken. Để tiêu diệt mọi thứ ngay lập tức thông qua AWS CLI (using a separate clean admin profile):

# 1. Delete the compromised Access Key immediately
aws iam delete-access-key --user-name CompromisedUser --access-key-id AKIAIOSFODNN7EXAMPLE

# 2. Attach an explicit 'Deny All' inline policy to the IAM User to immediately
#    invalidate any STS tokens minted by that user AND block all further actions:
aws iam put-user-policy --user-name CompromisedUser --policy-name EmergencyKillSwitch \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*"
    }]
  }'

Bước 2: Tìm kiếm người dùng, vai trò và khóa truy cập IAM cửa sau trong CloudTrail¶

Chạy các lệnh AWS CLI này để kiểm tra xem bot có tạo người dùng IAM cửa sau ẩn hay đính kèm khóa truy cập phụ vào một trong các tài khoản nhân viên hiện có của bạn trong cửa sổ hay không:

# List all IAM users created recently across the account
aws iam list-users --query 'Users[?CreateDate>=`2026-10-30`].[UserName,CreateDate]' --output table

# Audit CloudTrail for every API call made by the compromised user in the last 24 hours
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=CompromisedUser \
  --max-results 50 \
  --query 'Events[].[EventTime,EventName,EventSource]' --output table

Bước 3: Quét tất cả 30+ Khu vực AWS dành cho các phiên bản EC2 giả mạo, nhóm tự động mở rộng quy mô và công việc Bedrock/SageMaker¶

Tại sao nạn nhân vẫn nhận được $12,000 hóa đơn vào cuối tháng sau khi họ "kiểm tra bảng điều khiển EC2 và không thấy trường hợp nào"? Bởi vì Bảng điều khiển AWS chỉ hiển thị một vùng tại một thời điểm (e.g., us-east-1), trong khi bot quay 20 trường hợp trong ap-south-1 (Mumbai), eu-north-1 (Stockholm) và sa-east-1 (Sao Paulo) và ẩn chúng bên trong Nhóm chia tỷ lệ tự động EC2 (ASGs) để nếu bạn chấm dứt phiên bản EC2 theo cách thủ công, Nhóm Auto Scaling sẽ khởi chạy phiên bản thay thế 30 seconds sau này.

Chạy bản tóm tắt bash đa vùng này để liệt kê tất cả các phiên bản EC2 đang chạy hoặc đang chờ xử lý trên mọi vùng AWS đang hoạt động trong 10 seconds:

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "=== Checking Region: $region ==="
  aws ec2 describe-instances --region "$region" \
    --filters "Name=instance-state-name,Values=running,pending,stopped" \
    --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name,LaunchTime]' \
    --output table
done

Phần 3: Tìm hiểu bí mật từ lịch sử Git (git-filter-repo) & Xóa bộ đệm ẩn cam kết của GitHub¶

Khi thông tin xác thực đã hết ở cấp nhà cung cấp, bạn phải xóa chuỗi bí mật khỏi kho lưu trữ của mình .git cam kết lịch sử để cả đồng nghiệp và người dọn dẹp trong tương lai đều không thể nhìn thấy nó (and so GitHub's Push Protection stops blocking your branches).

1. Tại sao git rm .env + git commit KHÔNG xóa bí mật khỏi Git¶

Đang chạy git rm .env && git commit -m "remove env" chỉ xóa tệp khỏi cam kết mới nhất (HEAD); bí mật văn bản gốc vẫn có thể đọc được vĩnh viễn bên trong cam kết gốc (the parent commit) cho bất kỳ ai nhấp vào "Cam kết" trên GitHub.

2. Viết lại lịch sử kho lưu trữ một cách sạch sẽ bằng cách sử dụng git-filter-repo¶

1. Nếu chỉ là lần cam kết cuối cùng (HEAD) chứa đựng bí mật (and nobody else has pulled it yet):

   # Remove the sensitive file from the staging index while keeping it on your local disk
   git rm --cached .env
   echo ".env" >> .gitignore
   git add .gitignore
   git commit --amend --no-edit
   git push --force-with-lease origin main
   

2. Nếu bí mật bị chôn vùi, một số cam kết quay lại lịch sử của bạn (or inside a code file you want to keep): Sử dụng git-filter-repo (the official, fast replacement recommended by Git and GitHub instead of the deprecated git filter-branch):

   # Option A: Completely purge a file (.env) from every commit in history
   git filter-repo --path .env --invert-paths --force
   
   # Option B: Replace a specific secret string with '***REMOVED***' across all files in history
   echo "sk_live_51NzExampleSecretKey12345==>***REMOVED***" > expressions.txt
   git filter-repo --replace-text expressions.txt --force
   
   # Force-push the rewritten history to GitHub across all branches and tags
   git push origin --force --all
   git push origin --force --tags
   

3. Bẫy bộ đệm GitHub ẩn (Dangling Commit SHAs)¶

Ngay cả sau khi bạn chạy git filter-repo và git push --force, Các máy chủ web của GitHub vẫn giữ nguyên cam kết SHA cũ, không được tham chiếu ("lơ lửng") vẫn tồn tại và có thể truy cập công khai tại https://github.com/<owner>/<repo>/commit/<old-40-char-sha> (and in any forks or Pull Requests) cho đến khi quá trình thu gom rác chạy. - Cách xóa SHA cam kết được lưu trong bộ nhớ đệm trên GitHub ngay lập tức: 1. Sao chép đầy đủ 40-character cam kết SHA của cam kết bị rò rỉ trước khi bạn viết lại lịch sử. 2. Mở https://support.github.com/contact -> yêu cầu "Xóa dữ liệu nhạy cảm/Xóa chế độ xem được lưu trong bộ nhớ đệm đối với cam kết SHA không thể truy cập" trong kho lưu trữ owner/repo và cung cấp cam kết chính xác SHA (or use the GitHub Support portal's automated cache-purge workflow).

Phần 4: Làm thế nào để có được một $5,000 to $100,000+ Miễn phí hóa đơn Bot AWS hoặc GCP (The Courtesy Forgiveness Appeal)¶

Điều gì sẽ xảy ra nếu bạn đẩy một .env tập tin vào chiều thứ Sáu, mãi đến sáng thứ Hai mới kiểm tra email và thức dậy với một $28,400.00 Hóa đơn AWS hoặc Google Cloud từ các bot khai thác tiền điện tử hoặc LLM-proxy?

KHÔNG hoảng sợ và KHÔNG hủy thẻ tín dụng của bạn hoặc nộp yêu cầu bồi hoàn ngân hàng. Cả hai Amazon Web Services (AWS) và Nền tảng đám mây của Google (GCP) đã thiết lập nội bộ Điều chỉnh thanh toán rò rỉ thông tin xác thực do tai nạn một lần/Chính sách tín dụng lịch sự dành cho các nhà phát triển cá nhân, sinh viên và người khởi nghiệp, miễn là bạn hoàn thành 100% trong danh sách kiểm tra khắc phục bảo mật bắt buộc của họ trước khi nhóm Đánh giá thanh toán của họ đánh giá khiếu nại của bạn.

Giao thức miễn trừ hóa đơn AWS / GCP 5 bước (90%+ Success Rate for First-Time Leaks)¶

1. Trước tiên hãy hoàn thành mọi bước khắc phục bảo mật (AWS Will Reject Your Waiver Until the Account Is Clean):
   • Xóa Khóa truy cập IAM bị xâm phạm (and the IAM User if possible).
   • Chấm dứt mọi phiên bản EC2 trái phép, Nhóm tự động thay đổi quy mô, ổ đĩa EBS, IP đàn hồi, phiên bản RDS và nhóm S3 trên tất cả các khu vực (verify via AWS Cost Explorer and AWS Billing -> Bills -> Charges by Region that daily accrual has dropped back to $0.00).
   • Bật MFA ứng dụng phần cứng hoặc Authenticator (Multi-Factor Authentication) trên Tài khoản gốc AWS của bạn và mọi người dùng IAM.
2. Mở trường hợp hỗ trợ theo "Account and Billing" (Free for All AWS/GCP Tiers, No Paid Support Plan Required):
   • Đi đến console.aws.amazon.com/support/home -> Tạo trường hợp -> Tài khoản và thanh toán -> Dịch vụ: Thanh toán -> Danh mục: Tranh chấp một khoản phí / Tài khoản bị xâm phạm.
3. Gửi Bản tóm tắt chính xác về khắc phục và khó khăn thực tế này:
   • Xác nhận Dòng thời gian & Nguyên nhân: Nêu rõ thời điểm khóa vô tình bị lộ trên GitHub (e.g., "October 30 at 22:14 UTC") và khi nó bị thu hồi ("October 31 at 09:05 UTC").
   • Phân loại các khoản phí trái phép theo khu vực và dịch vụ: Liệt kê số tiền chính xác của hoạt động bot lừa đảo so với hóa đơn hàng tháng trước đây thông thường của bạn (e.g., "My normal monthly AWS bill for the past 8 months is $14.50/month in us-east-1; the unauthorized charges total $18,420.12 across ap-east-1, eu-north-1, and sa-east-1 EC2/Bedrock usage").
   • Xác nhận khắc phục 100%: Hãy gạch đầu dòng các bước chính xác mà bạn đã hoàn thành (1. Deleted IAM key AKIA...; 2. Terminated all unauthorized resources across all regions; 3. Audited CloudTrail for backdoor users; 4. Enabled Root & IAM MFA; 5. Configured AWS Budgets alerts).
   • Yêu cầu một cách lịch sự Điều chỉnh thanh toán ưu đãi một lần: Giải thích rằng bạn là một nhà phát triển cá nhân/sinh viên/người khởi nghiệp ở giai đoạn đầu, việc trả $18,420 hóa đơn bot trái phép sẽ gây ra khó khăn tài chính nghiêm trọng và yêu cầu tín dụng/miễn trừ hóa đơn ưu đãi một lần cho việc sử dụng gian lận.
4. Tạm thời hoán đổi hoặc giới hạn thẻ thanh toán được liên kết của bạn nếu sắp có tính năng tự động thanh toán:
   • Trong khi trường hợp Hỗ trợ thanh toán AWS của bạn đang được xem xét (which usually takes 5 to 15 business days trong khi Nhóm dịch vụ thanh toán và bảo mật AWS xác minh rằng tất cả tài nguyên giả mạo đã bị chấm dứt), hãy liên hệ với bộ phận Hỗ trợ AWS bên trong phiếu và yêu cầu họ đặt lệnh tạm giữ thanh toán tạm thời (defer auto-charge) trên hóa đơn đang tranh chấp để nó không thấu chi tài khoản ngân hàng của bạn trong khi việc điều chỉnh tín dụng đang được xử lý.

(Đối với các sự cố bảo mật làm việc từ xa và nhà phát triển có liên quan, hãy xem Mất cơ sở dữ liệu sản xuất do tai nạn, đẩy git, rò rỉ bí mật và phân loại sự cố, Cơ sở dữ liệu sản xuất bị hủy hoặc nhóm S3 bị xóa mà không có bản sao lưu gần đây, Vô tình gửi bảng lương bí mật, PII của khách hàng hoặc bảng tính HIPAA qua emailvà Bảo mật dữ liệu và bảo mật dữ liệu khi làm việc từ xa khẩn cấp.)

Cơ quan báo cáo về vi phạm dữ liệu và bảo mật đám mây khu vực¶

Câu hỏi thường gặp¶

Nếu tôi nhận ra mình đã đẩy một .env gửi tới kho lưu trữ GitHub công khai và đặt kho lưu trữ đó ở chế độ riêng tư 2 phút sau, tôi có cần xoay khóa của mình không?¶

Có, 100 phần trăm khóa trong tệp đó phải được coi là bị xâm phạm và bị thu hồi ngay lập tức. Các bot thu thập thông tin xác thực tự động không đợi Google lập chỉ mục kho lưu trữ của bạn; họ đăng ký trực tiếp với công chúng thời gian thực của GitHub `Events API` vòi cứu hỏa (`and GH Archive`), phát sóng tới mọi công chúng `PushEvent` trên toàn cầu trong vòng 1 đến 3 giây kể từ khi bạn `git push`. Vào thời điểm bạn nhấp vào "Cài đặt -> Thay đổi khả năng hiển thị kho lưu trữ -> Đặt ở chế độ riêng tư" hai phút sau, hàng chục bot quét tự động đã tải xuống khác biệt cam kết của bạn và xếp hàng thông tin đăng nhập AWS, Stripe, OpenAI và cơ sở dữ liệu của bạn để khai thác.

Tại sao các bot tiếp tục khởi chạy các phiên bản EC2 trong tài khoản AWS của tôi ngay cả sau khi tôi đã xóa thông tin bị rò rỉ AKIA phím truy cập?¶

Xóa tĩnh `AKIA...` khóa truy cập trong AWS IAM chỉ hủy kích hoạt khóa cố định cụ thể đó; nó không vô hiệu tạm thời `ASIA...` Dịch vụ mã thông báo bảo mật (`STS`) mã thông báo phiên mà kẻ tấn công đã tạo bằng cách sử dụng `sts:GetSessionToken` hoặc `sts:AssumeRole` trong vài giây đầu tiên sau khi cạo chìa khóa của bạn (`which remain valid for up to 12 to 36 hours`). Ngoài ra, các tập lệnh tấn công AWS tự động thường xuyên gọi `iam:CreateUser` và `iam:CreateAccessKey` ngay trong giây đầu tiên họ truy cập để tạo một tài khoản quản trị viên cửa sau ẩn thứ hai. Để ngăn chặn hoàn toàn hành vi xâm nhập AWS đang hoạt động, bạn phải xóa `AKIA` khóa, đính kèm một cách rõ ràng `Deny *` chính sách nội tuyến cho người dùng IAM bị xâm phạm (`which immediately invalidates all minted STS tokens`) và kiểm tra CloudTrail để tìm mọi người dùng hoặc vai trò IAM mới được tạo.

Liệu AWS hay Google Cloud có tha thứ cho một lỗi lớn không? $10,000+ hóa đơn nếu tin tặc đánh cắp khóa API của tôi từ GitHub và khai thác tiền điện tử?¶

Trong phần lớn các trường hợp rò rỉ ngẫu nhiên lần đầu tiên, có, miễn là bạn hành động nhanh chóng, hợp tác đầy đủ với nhóm bảo mật của họ và không bỏ qua hóa đơn. Cả AWS và Google Cloud đều có chính sách điều chỉnh thanh toán ưu đãi nội bộ một lần dành cho các nhà phát triển và doanh nghiệp nhỏ gặp phải tình trạng rò rỉ thông tin xác thực trái phép tăng đột biến. Trước khi yêu cầu miễn trừ hóa đơn trong phần hỗ trợ "Tài khoản và thanh toán", trước tiên bạn phải chứng minh rằng rò rỉ đã được đóng 100%: thu hồi các khóa IAM bị lộ, chấm dứt tất cả các phiên bản điện toán giả mạo và Nhóm tự động mở rộng quy mô trên tất cả hơn 30 khu vực toàn cầu, bật Xác thực đa yếu tố (`MFA`) trên tài khoản gốc của bạn và thiết lập cảnh báo chi phí AWS Budgets.

Tại sao git rm .env không xóa khóa bí mật của tôi khỏi GitHub?¶

Git là một sổ cái kiểm soát phiên bản bất biến: khi bạn chạy `git rm .env` và đẩy một cam kết mới, Git chỉ ghi lại rằng tệp không có trong ảnh chụp nhanh mới nhất (`HEAD`), trong khi vẫn giữ toàn bộ nội dung bản rõ của `.env` được lưu trữ vĩnh viễn bên trong cam kết trước đó (`the parent commit`) trong lịch sử cam kết của kho lưu trữ của bạn. Ngay cả khi bạn viết lại lịch sử của mình với `git filter-repo` và ép buộc, bất kỳ ai vẫn có thể đọc được bí mật nếu bạn chưa thu hồi nó trên bảng điều khiển của nhà cung cấp. Trước tiên, hãy luôn thu hồi và xoay khóa bí mật trong bảng điều khiển của nhà cung cấp đám mây của bạn, sau đó sử dụng `git filter-repo` để xóa chuỗi chết khỏi lịch sử cam kết của bạn.

Hướng dẫn liên quan¶

• Mất cơ sở dữ liệu sản xuất do tai nạn, đẩy git, rò rỉ bí mật và phân loại sự cố
• Cơ sở dữ liệu sản xuất bị hủy hoặc nhóm S3 bị xóa mà không có bản sao lưu gần đây
• Vô tình gửi bảng lương bí mật, PII của khách hàng hoặc bảng tính HIPAA qua email tới nhầm người nhận
• Vô tình chia sẻ màn hình bảng lương bí mật, trình quản lý mật khẩu hoặc danh sách sa thải trên Zoom/Teams
• Bảo mật dữ liệu và bảo mật dữ liệu khi làm việc từ xa khẩn cấp
• Số khẩn cấp

Nguồn và hướng dẫn chính thức¶

• Dịch vụ web của Amazon (AWS Security Incident Response Guide & AWS Knowledge Center: "What should I do if I notice unauthorized activity or exposed IAM access keys?"): AWSCompromisedKeyQuarantineV2 Hành vi chính sách, vô hiệu hóa tạm thời STS Mã thông báo phiên (RevokeOldSessions) và Kiểm tra tài nguyên đa khu vực.
• Tài liệu GitHub (GitHub Secret Scanning, Push Protection, & "Removing sensitive data from a repository" using git-filter-repo): Chương trình tự động thu hồi đối tác (Stripe, AWS, OpenAI, NPM), git-filter-repo Viết lại lịch sử và xóa các SHA cam kết được lưu trong bộ nhớ đệm không thể truy cập được.
• Stripe Inc. (Stripe Developer Security Guide: API Key Rotation & Compromised Key Incident Triage): Ngay lập tức sk_live_ Hết hạn khóa, kiểm tra /v1/events và /v1/webhook_endpointsvà hạn chế khóa thông qua rk_live_ Phạm vi.
• NIST (Special Publication 800-61 Rev. 2 / Rev. 3: Computer Security Incident Handling Guide) & OWASP (Secrets Management Cheat Sheet): Ngăn chặn thông tin xác thực, Liên kết nhận dạng khối lượng công việc OIDC tạm thời (replacing static CI/CD keys) và Quét bí mật cam kết trước.