☁️ Infrastruktur & Keselamatan Awan 🔒 Pematuhan CIS Benchmark v3.0

Amalan Terbaik AWS MFA: Mengamankan Akaun Root dan Pengguna IAM dengan MFA Maya

Manual keselamatan awan perusahaan: memenuhi kawalan CIS AWS Benchmark, mengunci akaun Root merentasi pelbagai token FIDO2/maya, menguatkuasakan syarat MFA dasar IAM, mengautomasikan sesi AWS CLI STS, kekangan andaian peranan (role assumption), dan pemulihan bencana.

2FA Pasukan Kejuruteraan Keselamatan 2FA-Tool
Dikemas kini Oktober 2026 · 9 min bacaan
📌 Ringkasan Eksekutif & Matriks AWS Well-Architected

Di bawah Model Tanggungjawab Bersama AWS (Shared Responsibility Model), sementara AWS menguruskan "Keselamatan Awan" (Security OF the Cloud) (pusat data fizikal, perkakasan hos, hipervisor), pelanggan memegang akauntabiliti mutlak untuk "Keselamatan DALAM Awan" (Security IN the Cloud)—khususnya tadbir urus identiti, kebersihan kelayakan akses, dan kawalan capaian. Kompromi akaun AWS Root tanpa sekatan atau kelayakan IAM berkeistimewaan membolehkan pelaku ancaman melancarkan ribuan dolar contoh pengkomputeran perlombongan kripto GPU haram, mengekstrak tasik data privasi S3, atau melakukan pemadaman tebusan yang membawa malapetaka.

Garis Dasar CIS Benchmark Kawalan Seksyen 1.5 & 1.6

MFA adalah mandatori untuk semua pengguna konsol pentadbiran dan tidak boleh dirunding bagi akaun AWS Root.

Lebihan Berbilang MFA Sehingga 8 Peranti MFA

AWS membenarkan pendaftaran sehingga 8 token FIDO2 dan TOTP maya yang berbeza bagi setiap akaun, menghapuskan titik kegagalan tunggal.

Penguatkuasaan Programatik aws:MultiFactorAuthPresent

Dasar penolakan bersyarat global IAM menyekat semua panggilan API tanpa kebenaran sehingga pengesahan MFA aktif dicapai.

1

Garis Dasar Pematuhan Awan: CIS Benchmark & Rangka Kerja Kawal Selia

Sama ada organisasi kejuruteraan anda sedang mengejar perakuan SOC 2 Type II, pensijilan ISO 27001, pengesahan PCI DSS 4.0, atau menyelaraskan dengan Rukun Keselamatan AWS Well-Architected, pelaksanaan MFA merentasi identiti IAM merupakan syarat pintu masuk asas:

Standard / Standard Pematuhan Spesifikasi Kawalan Keterukan / Mandat Mekanisme Pengesahan Audit
CIS AWS Foundations Benchmark v3.0 1.5 / 1.6 / 1.10 Tahap 1 (Mandatori) Penilaian automatik AWS Security Hub / Prowler
PCI DSS 4.0 Keperluan 8.4.2 Mandatori Audit konsol Persekitaran Data Pemegang Kad (CDE) & API
SOC 2 Type II (Kriteria Kepercayaan) CC6.1 / CC6.2 Kawalan Utama Pemeriksaan bebas CPA terhadap Laporan Kelayakan IAM
Pelancaran Mandatori AWS MFA Dasar AWS 2024–2026 Penguatkuasaan Platform Sekatan gerbang log masuk Root sehingga pendaftaran MFA selesai
2

Keperluan Mutlak Mengamankan Akaun Root AWS

Dalam sempadan akaun AWS, akaun Root mewakili identiti serba kuasa yang dicipta pada saat akaun dimulakan. Tidak seperti peranan atau pengguna IAM, tindakan akaun Root tidak boleh dihadkan oleh dasar berasaskan identiti IAM atau Service Control Policies (SCP) dalam akaun kendiri.

Radius Letupan Bencana Akibat Akaun Root Dikompromi:

  • Penutupan Akaun yang Tidak Boleh Dibatalkan: Pelaku ancaman boleh menekan "Close Account", menjadualkan pemusnahan infrastruktur secara kekal.
  • Perampasan Kewangan & Pengebilan: Menghalakan semula invois, menggantikan kad kredit pembayaran korporat, dan menggunakan beratus-ratus contoh titik GPU (GPU spot instances) merentasi 30+ rantau AWS untuk perlombongan mata wang kripto haram.
  • Memutuskan Struktur AWS Organizations: Mengeluarkan akaun ahli daripada pepohon pengurusan, meruntuhkan pemantauan pematuhan organisasi.
  • Mengubah Hubungan Keselamatan Utama: Menukar e-mel root dan rekod telefon memutuskan saluran campur tangan sokongan rasmi AWS secara kekal.
🛡️ Tiga Prinsip Kebersihan Root yang Tidak Boleh Diubah:
  1. Sifar Kunci Akses Root: Audit Laporan Kelayakan IAM untuk mengesahkan bahawa kunci akses bagi akaun Root tidak wujud. Jika ada, padamkannya dengan segera.
  2. Penyimpanan Kata Laluan Kawalan Berganda (Dual-Custody): Jana kata laluan rawak 32+ aksara, bahagikan frasa laluan antara CISO dan Ketua Penasihat Undang-undang, dan kunci bahagian tersebut di dalam peti besi kalis api fizikal.
  3. Lebihan Berbilang Peranti (Sehingga 8 Peranti): Daftarkan sekurang-kurangnya dua kunci perkakasan FIDO2 fizikal (YubiKey) serta peranti sandaran TOTP Maya luar talian yang disimpan sejuk.
3

Matriks Pemilihan MFA: TOTP Maya lwn FIDO2 Perkakasan (YubiKey)

AWS menyokong tiga kelas peranti MFA utama. Jurubina awan perlu menyelaraskan pemilihan berdasarkan model ancaman dan tahap keistimewaan pentadbiran:

MFA Maya Perisian

Aplikasi TOTP Maya

Token RFC 6238 standard (Google Authenticator, 1Password, 2FA-Tool). Onboarding pantas, sifar geseran perolehan. Sesuai untuk pembangun standard.

FIDO2 / WebAuthn Perkakasan

Siri YubiKey 5

Kriptografi Tahan Pemancingan Data (Phishing-Resistant). Penegasan kunci awam terikat asal menggagalkan kit pancingan data proksi terbalik. Mandatori untuk Root & Pentadbir.

Token Perkakasan Khusus

Kad Gemalto / Thales

Kad TOTP berkuasa kendiri tanpa wayar (air-gapped) dengan skrin LCD. Penting untuk kemudahan selamat tanpa peranti luar (SCIF) di mana telefon pintar dan kunci USB dilarang.

Protokol Peti Besi Kawalan Berganda & FIPS 140-2 Tahap 3 Perkakasan Perusahaan MFA:

Bagi syarikat Fortune 500 dan kontraktor pertahanan, keselamatan akaun Root mewajibkan fob kunci perkakasan khusus (cth., fob SafeNet/Gemalto IDPrime) yang diperakui di bawah FIPS 140-2 Tahap 3. Tidak seperti aplikasi telefon pintar, fob fizikal ini tidak mempunyai antara muka wayarles, tiada radio bluetooth, dan tidak boleh ditangkap melalui perisian pengintip mudah alih.

Tadbir Urus Kawalan Berganda Fizikal: Dalam protokol pusat data perusahaan, akses Root memerlukan dua individu berbeza: seorang penjaga memegang kelayakan e-mel induk, manakala seorang pegawai keselamatan bebas memegang kunci fizikal peti besi selamat yang mengandungi token perkakasan Root. Tiada mana-mana pihak boleh mengakses akaun AWS Root secara unilateral.

4

Menguatkuasakan MFA melalui Dasar IAM (Pelaksanaan JSON)

Garis dasar keselamatan tidak boleh bergantung pada tindakan sukarela pekerja. Tadbir urus awan memerlukan penguatkuasaan peringkat dasar: pengguna tanpa pengesahan MFA aktif mesti dinafikan secara sistematik daripada semua tindakan API dan Konsol AWS, kecuali keupayaan untuk mendaftarkan peranti MFA mereka sendiri.

// Dasar IAM gred pengeluaran: Enforce-MFA-Self-Management-Policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowViewAccountInfo",
      "Effect": "Allow",
      "Action": [
        "iam:GetAccountPasswordPolicy",
        "iam:ListVirtualMFADevices"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowManageOwnVirtualMFADevice",
      "Effect": "Allow",
      "Action": [
        "iam:CreateVirtualMFADevice",
        "iam:DeleteVirtualMFADevice"
      ],
      "Resource": "arn:aws:iam::*:mfa/${aws:username}"
    },
    {
      "Sid": "AllowManageOwnUserMFA",
      "Effect": "Allow",
      "Action": [
        "iam:DeactivateMFADevice",
        "iam:EnableMFADevice",
        "iam:ListMFADevices",
        "iam:ResyncMFADevice"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "BlockAllAccessUnlessMFAAuthenticated",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "iam:GetUser"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}
Pecahan Logik Penilaian:

Kenyataan 4 menilai kunci syarat global "aws:MultiFactorAuthPresent": "false" menggunakan penafian eksplisit Deny. Kerana penafian eksplisit mengatasi semua pernyataan Benarkan (Allow), sesi tanpa MFA disekat serta-merta merentasi semua API AWS, mengarahkan pengguna terus ke skrin pendaftaran kendiri.

5

Pengesahan MFA AWS CLI & SDK: Token Sesi Sementara STS

Apabila dasar IAM menguatkuasakan MFA, pembangun yang menjalankan arahan seperti aws s3 ls atau melaksanakan kod Terraform akan menerima ralat AccessDenied. Kunci akses jangka panjang tidak boleh meminta OTP secara interaktif. Jurutera mesti menggunakan AWS STS (Security Token Service) untuk menukar kunci jangka panjang + TOTP 6-digit dengan kelayakan sementara:

Skrip Automasi (aws-mfa-session.sh):

Letakkan skrip pembantu ini dalam persekitaran tempatan anda (~/.aws/aws-mfa-session.sh) untuk mengautomasikan perolehan token:

#!/usr/bin/env bash
# Tukar Kunci Jangka Panjang AWS + Kod MFA untuk Token Sesi STS
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Masukkan Kod OTP 2FA 6-digit: "
read -r TOKEN_CODE

SESSION_JSON=$(aws sts get-session-token \
  --serial-number "$MFA_ARN" \
  --token-code "$TOKEN_CODE" \
  --duration-seconds 43200 \
  --output json)

if [ $? -eq 0 ]; then
  export AWS_ACCESS_KEY_ID=$(echo "$SESSION_JSON" | jq -r '.Credentials.AccessKeyId')
  export AWS_SECRET_ACCESS_KEY=$(echo "$SESSION_JSON" | jq -r '.Credentials.SecretAccessKey')
  export AWS_SESSION_TOKEN=$(echo "$SESSION_JSON" | jq -r '.Credentials.SessionToken')
  echo "✅ Pengesahan berjaya! Sesi sementara dieksport (Sah selama 12 jam)."
else
  echo "❌ Pengesahan gagal. Semak kod token atau hanyutan masa peranti."
fi
6

AssumeRole Rentas Akaun dengan Kekangan MFA

Dalam seni bina perusahaan berbilang akaun, jurutera berkeistimewaan biasanya mengesahkan ke akaun Identiti terpusat dan beralih ke akaun sasaran (Pengeluaran, Pementasan) melalui sts:AssumeRole. Bagi memastikan bahawa kebenaran pengeluaran tinggi tidak boleh dirampas melalui kelayakan yang bocor, hubungan kepercayaan peranan pengeluaran mesti menguatkuasakan syarat MFA:

// Dasar Amanah Peranan Sasaran yang memerlukan MFA aktif
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

Corak seni bina ini memastikan bahawa walaupun penyerang mengompromi kelayakan dalam akaun Identiti pusat, cubaan untuk menganggap peranan sasaran tanpa memenuhi MFA mencetuskan ralat AccessDenied serta-merta pada sempadan token keselamatan.

7

Pengauditan CloudTrail & Amaran Masa Nyata EventBridge

Pengesahan pematuhan automatik memerlukan pengesanan serta-merta apabila mana-mana pengguna mengakses Konsol Pengurusan AWS tanpa pengesahan berbilang faktor. Dengan menangkap peristiwa AWS CloudTrail dan menghalakannya melalui Amazon EventBridge, pasukan SecOps mencapai amaran masa nyata:

// Corak Peraturan EventBridge: Log Masuk Konsol Tanpa MFA
{
  "source": ["aws.signin"],
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": {
    "eventName": ["ConsoleLogin"],
    "additionalEventData": {
      "MFAUsed": ["No"]
    }
  }
}

Sebaik sahaja peristiwa diterima, EventBridge mencetuskan pemberitahuan Amazon SNS ke alat kelui pegawai bertugas Pusat Operasi Keselamatan (SOC) atau memanggil fungsi AWS Lambda yang membatalkan sesi pengguna IAM aktif dengan segera.

8

Tadbir Urus Berbilang Akaun: AWS Organizations & IAM Identity Center

Dalam persekitaran perusahaan yang menguruskan puluhan atau ratusan akaun AWS merentasi Landing Zones, menyediakan pengguna IAM individu dalam setiap akaun ialah corak anti-amalan.

Penyatuan Identiti Terpusat:

Gunakan AWS IAM Identity Center (dahulunya AWS SSO) dalam Akaun Pengurusan yang ditetapkan. Satukan identiti terhadap IdP korporat (Okta, Microsoft Entra ID, PingFederate). Kuatkuasakan MFA korporat pada peringkat IdP, sambil melampirkan Service Control Policies (SCP) pada punca Organisasi untuk menafikan tindakan root ahli:

"Action": "*", "Resource": "*",
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }

SCP Gred Pengeluaran: Menguatkuasakan Kekangan MFA Merentasi Semua Akaun Ahli

Dalam organisasi besar, pentadbir akaun individu mungkin secara tidak sengaja memberikan keistimewaan berlebihan. Dengan melampirkan Service Control Policy (SCP) pada peringkat Punca Organisasi atau Unit Organisasi (OU), pasukan tadbir urus awan menetapkan benteng yang tidak boleh diubah: panggilan API berimpak tinggi dinafikan tanpa syarat melainkan dibenarkan oleh sesi MFA yang aktif:

// SCP AWS Organizations: Tolak operasi API pemusnah tanpa MFA aktif
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCriticalActionsWithoutMFA",
      "Effect": "Deny",
      "Action": [
        "iam:CreateAccessKey",
        "iam:CreateLoginProfile",
        "s3:DeleteBucket",
        "kms:ScheduleKeyDeletion",
        "ec2:TerminateInstances"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Rantaian Peranan (Role Chaining) & Kekangan Jangka Hayat Token STS:

Apabila identiti IAM menganggap peranan perantara yang seterusnya menganggap peranan sekunder ("rantaian peranan"), AWS STS menanggalkan konteks aws:MultiFactorAuthPresent asal daripada token sesi hiliran! Bagi mengekalkan pematuhan ketat dari hujung ke hujung merentasi saluran paip rentas akaun, bina graf andaian peranan secara langsung daripada sesi IAM Identity Center yang telah disahkan dan bukannya merangkaikan beberapa peranan IAM perantara.

9

Pemulihan Bencana: Protokol Kehilangan Peranti MFA Root

Apakah yang berlaku jika semua token perkakasan dan peranti maya Root MFA yang didaftarkan musnah dalam malapetaka?

Urutan Pemulihan Luar Saluran (Out-of-Band) Rasmi:

  1. Mulakan Log Masuk Root: Masukkan e-mel akaun Root dan kata laluan induk pada Konsol AWS.
  2. Selesaikan Masalah MFA: Pada prompt MFA, klik "Troubleshoot MFA".
  3. Pengesahan E-mel Utama: AWS menghantar pautan pengesahan terhad masa ke alamat e-mel utama Root. Sahkan cabaran e-mel tersebut.
  4. Cabaran Suara Automatik: Klik "Call me now". Sistem pengesahan automatik AWS menghubungi nombor telefon akaun utama yang berdaftar dan membacakan PIN pengesahan 6-digit.
Peringatan Kritikal: Pastikan Maklumat Hubungan Utama Sentiasa Dikemas Kini!

Jika organisasi anda menukar nombor telefon atau individu yang dihubungi telah meletak jawatan tanpa mengemas kini Tetapan Akaun AWS, pemulihan automatik akan gagal. Resolusi manual memerlukan penyerahan surat ikatan pendaftaran syarikat yang disahkan oleh notari awam kepada bahagian AWS Trust & Safety, dengan masa semakan mengambil masa 3–7 hari bekerja.

10

Soalan Lazim Jurubina Awan Perusahaan (FAQ)

Bolehkah token MFA AWS Root dikongsi dalam kalangan pasukan DevOps? ▼

Dilarang sama sekali. Berkongsi kelayakan MFA Root menggagalkan semua audit pematuhan (SOC 2, ISO 27001). Pentadbiran rutin mesti mengalir melalui peranan IAM Identity Center dengan akauntabiliti individu. Kelayakan Root mesti kekal terkunci di dalam peti besi kawalan berganda fizikal hanya untuk insiden kecemasan terbesar (break-glass events).

Bagaimanakah kunci syarat aws:MultiFactorAuthAge meningkatkan keselamatan? ▼

Kunci ini menguatkuasakan kesegaran sesi. Mengkonfigurasi "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} memerlukan token MFA dikemukakan dalam tempoh 3,600 saat (1 jam) sebelumnya. Tindakan berisiko tinggi (cth., menamatkan kluster RDS) akan disekat jika sesi lebih lama daripada tempoh ini, melindungi daripada perampasan sesi jangka panjang.

Bolehkah saya menggunakan pengesah dalam talian 2FA-Tool untuk memperuntukkan AWS Virtual MFA? ▼

Ya. AWS Virtual MFA mematuhi spesifikasi TOTP RFC 6238 dengan ketat (HMAC-SHA1, selang 30 saat, 6 digit). Anda boleh memasukkan rentetan rahsia Base32 ke dalam 2FA-Tool.com untuk menjana dua kod pengesahan berturut-turut yang diperlukan untuk pendaftaran, 100% secara tempatan dalam pelayar anda.

Pengiraan Bahagian Klien Zero-Trust

Uji Token TOTP Perusahaan Secara Selamat

Jana kod pengesahan TOTP RFC 6238 standard serta-merta dengan API Web Crypto W3C. Tiada panggilan pelayan, pembendungan memori mutlak, sifar kebocoran.