Logging SSH dan Manajemen Sesi Menggunakan AWS SSM

Diterbitkan: 2022-03-11

Menyiapkan alat atau skrip khusus untuk menyimpan log SSH di Linux bisa jadi membosankan dan rawan kesalahan.

Insinyur dapat menggunakan rooth , screen , atau utilitas lain untuk mencatat aktivitas pengguna tetapi jika izin pengguna tidak diatur dengan benar, pengguna yang terampil dapat menghapus log audit untuk menutupi jejak mereka. Pilihan lain adalah mengatur logging di tingkat kernel, tetapi keahlian yang dibutuhkan untuk itu tidak begitu umum.

Untungnya, ada cara untuk mencatat aktivitas pengguna tanpa menulis satu pun perintah Linux! Kami akan membutuhkan layanan ini:

  • EC2
  • IAM (Manajemen Identitas dan Akses)
  • KMS (Layanan Manajemen Kunci)
  • CloudWatch Logs (dan/atau S3)
  • AWS Systems Manager (sebelumnya dikenal sebagai SSM)

Mari kita lihat cara mengaturnya masing-masing.

EC2 dan IAM

Meluncurkan instans EC2 biasanya cukup mudah, tetapi ada satu tugas utama yang harus dilakukan selama peluncuran: Kami perlu melampirkan peran IAM ke instans kami, jika tidak, kami tidak akan dapat mencapai hasil yang diharapkan yang dirinci di akhir ini artikel.

Peran IAM yang kami kaitkan dengan instans EC2 kami harus memiliki kebijakan AmazonSSMManagedInstanceCore bawaan , ditambah kebijakan ini (dilampirkan sebagai inline atau dikelola pelanggan):

 { "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:CreateLogStream", "logs:DescribeLogStreams", "logs:DescribeLogGroups", "logs:PutLogEvents" ], "Effect": "Allow", "Resource": "*" } ] }

Selain peran IAM, kami biasanya menggunakan konfigurasi instans EC2 ini:

  • OSnya adalah Amazon Linux 2, karena secara default sudah terpasang AWS Systems Manager Agent (SSM Agent). (Begitu juga distribusi Ubuntu, yang juga merupakan opsi.)
  • Jenis Instance adalah t3.micro (tetapi semua jenis dapat digunakan).
  • Grup Keamanan default yang ditetapkan AWS ke VPC akan berfungsi, karena kami tidak memerlukan port SSH terbuka untuk latihan ini.

Kita dapat mulai menyiapkan KMS tanpa menunggu instans EC2 melakukan booting.

KMS

Kami memerlukan kunci KMS jika kami ingin semua log sesi yang dikirim ke CloudWatch disimpan dengan terenkripsi. Mari menuju ke layanan KMS dan membuat kunci.

Tangkapan layar AWS dengan remah roti "KMS", "Kunci yang dikelola pelanggan", dan "Buat kunci", saat ini di Langkah 1: "Konfigurasikan kunci". "Jenis kunci" dapat disetel ke "Simetris" (dipilih) atau "Asimetris". Di bawah "Opsi lanjutan", setelan "Asal bahan utama" dapat berupa "KMS" (dipilih), "Eksternal", atau "Penyimpanan kunci khusus (CloudHSM)".
Langkah 1: Memilih jenis kunci simetris.

Tangkapan layar AWS dengan remah roti yang sama, sekarang di Langkah 2: "Tambahkan label." Bidang Alias ​​​​diatur ke "cwlg," bidang Deskripsi opsional dibiarkan kosong, dan bidang Tag opsional tidak menambahkan tag.
Langkah 2: Memberi nama kunci kami.

Tangkapan layar AWS dengan remah roti yang sama, sekarang di Langkah 3: "Tentukan izin administratif utama." Bidang pertama, "Administrator kunci", memiliki kotak pencarian kosong dengan 10 baris hasil (halaman 1 dari 3) dengan kolom Nama, Jalur, dan Jenis. Hanya baris pertama (dengan masing-masing nilai kolom "admin," "/," dan "User") yang kotak centangnya terkait. Bidang lainnya, "Penghapusan kunci," memiliki satu opsi, "Izinkan administrator kunci untuk menghapus kunci ini," yang kotak centangnya juga dicentang.
Langkah 3 (opsional): Menetapkan administrator.

Kami menyarankan untuk menugaskan administrator agar kunci dapat dikelola oleh pengguna selain pengguna root akun AWS, tetapi jika orang lain tidak memerlukan akses, kami dapat melewati Langkah 3.

Di sini kami memilih "admin" pengguna IAM sebagai administrator kunci, tetapi kami bebas memilih pengguna atau peran apa pun. Kami juga dapat memilih untuk menonaktifkan izin penghapusan kunci untuk administrator.

Tangkapan layar AWS dengan remah roti yang sama, sekarang di Langkah 4: "Tentukan izin penggunaan kunci." Bidang pertama, "Akun ini", memiliki hasil penelusuran yang sama seperti pada Langkah 3, tetapi tidak ada yang dicentang. Bidang lain, "Akun AWS lainnya," tidak menambahkan apa pun ke dalamnya.
Langkah 4: Melewati halaman tugas pengguna.

Kami tidak akan menugaskan pengguna ke kunci ini karena kami ingin kunci ini hanya digunakan oleh layanan CloudWatch Logs untuk operasi enkripsi dan dekripsi log SSH.

Tangkapan layar AWS dengan remah roti yang sama, sekarang di Langkah 5: "Tinjau." Kolom pertama, "Konfigurasi kunci", mencantumkan "Jenis kunci" sebagai "Simetris", "Spesifikasi kunci" sebagai "SYMMETRIC_DEFAULT", "Penggunaan kunci" sebagai "Enkripsi dan dekripsi", dan "Asal" sebagai "AWS_KMS ." Bidang berikutnya, "Alias ​​dan deskripsi," mencantumkan satu Alias, "cwlg," tanpa Deskripsi. Bidang berikutnya, "Tag", tidak menunjukkan data. Bidang terakhir, "Kebijakan kunci", menyertakan kotak teks yang telah diisi sebelumnya dengan kebijakan dalam format JSON.
Langkah 5: Tinjau konfigurasi kami dan tukar kebijakan kunci default.

Pada halaman Tinjau, kita perlu mengubah kebijakan kunci yang dihasilkan KMS karena tidak menyertakan izin untuk CloudWatch Logs untuk menggunakan kunci tersebut. Kami akan menggantinya dengan kebijakan ini:

 { "Version": "2012-10-17", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow access for Key Administrators", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:user/USERNAME" }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" }, { "Sid": "Allow access to CloudWatch Log", "Effect": "Allow", "Principal": { "Service": "logs.REGION.amazonaws.com" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*", "Condition": { "ArnLike": { "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:REGION:ACCOUNT_ID:*" } } } ] }

Pastikan untuk mengganti semua placeholder:

  • ACCOUNT_ID menjadi ID akun AWS kami.
  • USERNAME menjadi nama pengguna administrator yang dipilih pada Langkah 3. Jika kami memilih keluar dari langkah itu, di sini kami menghapus blok pernyataan kedua (blok dengan "Sid": "Allow access for Key Administrators" ).
  • REGION menjadi kode pengenal regional tempat kami menerapkan layanan (misalnya, us-west-1 ).

Dengan itu, KMS siap digunakan.

Grup Log CloudWatch

Selanjutnya kita memerlukan grup CloudWatch Log (dan/atau ember S3—lihat di bawah) tempat Agen SSM dapat mengirim log sesi SSH. Mari kita ciptakan.

Tangkapan layar AWS dengan remah roti "CloudWatch", "CloudWatch Logs", "Grup log", dan "Buat grup log". Tidak ada sidebar multilangkah. Bidang pertama, "Log detail grup", memiliki tiga sub-bidang: "Log nama grup" (setel ke "ssm-session-demo"), "Pengaturan retensi" (setel ke "Jangan pernah kedaluwarsa" dari dropdown), dan "KMS kunci ARN - opsional" (diatur ke nilai terpotong yang dimulai dengan "arn:aws:kms"). Bidang kedua, "Tag", tidak memiliki tag.
Membuat grup log “CloudWatch Logs”.

Perhatikan bidang ARN kunci KMS: AWS memberi kami nilai yang diperlukan di sini setelah kunci dibuat di Langkah 5 bagian KMS.

(Jika kami tidak mengaitkan kebijakan yang benar dengan kunci KMS kami sebelumnya, yang mengizinkan layanan CloudWatch Logs untuk menggunakan kunci tersebut, kami akan menerima kesalahan yang terkait dengan kunci KMS pada saat ini.)

Menyimpan Log SSH dalam Bucket S3

Untuk menyimpan log aktivitas dengan S3 alih-alih—atau sebagai tambahan—CloudWatch Logs, kami perlu menambahkan izin ini ke profil instans EC2 kami sebagai kebijakan terpisah (atau menggabungkannya secara manual dengan izin lain yang mungkin perlu kami kaitkan):

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::BUCKET_NAME/*" }, { "Effect": "Allow", "Action": [ "s3:GetEncryptionConfiguration" ], "Resource": "*" }, { "Effect": "Allow", "Action": "kms:GenerateDataKey", "Resource": "*" } ] }

Dalam cuplikan di atas, pastikan untuk mengganti placeholder BUCKET_NAME .

Sekarang setelah kami menyiapkan tempat untuk menyimpan log—CloudWatch Logs, bucket S3, atau keduanya—kami siap untuk memasuki sesi SSH.

Manajer Sesi Manajer Sistem AWS

Ini adalah langkah kunci terakhir, di mana kami mengonfigurasi akses aman ke mesin Linux kami untuk pemantauan dan pencatatan sesi SSH. Kita akan mulai di dasbor Session Manager.

Tangkapan layar dasbor AWS Session Manager dengan bagian, "Cara kerjanya", "Mengapa menggunakan Pengelola Sesi?", "Memulai", "Sumber daya lainnya", dan di sudut kanan atas, "Mulai sesi". Bagian terakhir memiliki tombol oranye "Mulai Sesi" dan tombol putih "Konfigurasikan Preferensi".
Langkah 1: Memulai dengan dasbor.

Di dasbor, klik tombol putih "Konfigurasikan Preferensi" di kanan atas kotak "Mulai sesi" untuk mengaktifkan pencatatan sesi.

Pada halaman Preferensi, kami akan menemukan beberapa bagian yang dapat kami jelajahi, tetapi fokus kami adalah streaming log sesi SSH ke CloudWatch atau S3 untuk memungkinkan kami melihat dengan cepat apa yang terjadi di dalam mesin Linux kami.

Tangkapan layar bagian AWS berjudul "CloudWatch logging". Pengaturan pertamanya, juga disebut "CloudWatch logging," memiliki kotak centang berlabel Aktifkan yang dicentang. Pengaturan berikutnya, "Pilih opsi logging pilihan Anda", memilih "Stream sesi log (Disarankan)" daripada "Unggah log sesi". Pengaturan berikutnya, "Terapkan enkripsi," memiliki kotak centang berlabel "Izinkan hanya grup log CloudWatch terenkripsi" yang dicentang. Pengaturan terakhir, "Grup log CloudWatch," memilih "Pilih nama grup log dari daftar" alih-alih "Masukkan grup log di kotak teks." Di bawahnya ada daftar, "Grup log CloudWatch," dengan "ssm-session-demo" dipilih. Ini memiliki kolom yang sesuai "Enkripsi" (diatur ke "Terenkripsi"), "Kedaluwarsa setelah" (diatur ke "Tidak pernah kedaluwarsa"), "Filter metrik" (diatur ke 0), "Byte yang disimpan" (diatur ke 0), dan stempel waktu "Waktu pembuatan".
Langkah 2a: Mengaktifkan pencatatan CloudWatch.

Tepat setelah bagian “CloudWatch logging”, ada bagian “S3 logging” di mana kita dapat memilih bucket.

Tangkapan layar bagian AWS berjudul "S3 logging". Pengaturan pertamanya, "Kirim log sesi ke S3," memiliki kotak centang berlabel "Aktifkan" yang dicentang. Pengaturan berikutnya, "Terapkan enkripsi," memiliki kotak centang berlabel "Izinkan hanya ember S3 terenkripsi" yang dicentang. Pengaturan berikutnya, "Pilih ember S3," memilih "Pilih nama ember dari daftar" alih-alih "Masukkan nama ember di kotak teks." Di bawahnya, "ssm-session-demo" dipilih dari daftar drop-down. Bidang terakhir, "Awalan kunci S3 - opsional," kosong.
Langkah 2b: Mengaktifkan logging S3.

Setelah SSH logging dikonfigurasi, kita dapat memasukkan SSH ke mesin Linux kita dan menjalankan beberapa perintah untuk melihat apakah aktivitas tersebut ditangkap atau tidak.

Jadi, mari kita mulai sesi. Pada halaman yang sama, kita akan menemukan tab “Sessions” di mana kita dapat memulai sesi. Mengklik tombol "Mulai sesi" akan memberi kami daftar mesin EC2 tempat kami dapat memulai sesi:

Tangkapan layar AWS dengan breadcrumb AWS Systems Manager, Session Manager, dan Start a session. Kotak telusur "Target instance" tidak memiliki kueri yang diisi dan hanya satu hasil, dengan "Nama instance" disetel ke "Demo SSM".
Langkah 3: Memilih instans EC2 kami untuk memulai sesi SSH.

Jika kami tidak melihat instance EC2 Linux kami dalam daftar, kami harus memeriksa apakah instance tersebut dalam keadaan berjalan dan memiliki izin IAM yang terkait dengannya seperti yang kami jelaskan sebelumnya.

Menangani Kesalahan Agen SSM “Tidak Mendukung Log Streaming”

Jika kami menerima kesalahan yang mengatakan bahwa versi Agen SSM yang diinstal pada mesin EC2 kami tidak mendukung streaming log CloudWatch, jangan khawatir. Ada cara tanpa rasa sakit untuk memperbaikinya.

Tangkapan layar pesan kesalahan AWS dengan teks putih di latar belakang merah. Tanda X yang dilingkari ada di sebelah pesan, "Versi Agen SSM yang diinstal pada instans ini tidak mendukung log streaming ke CloudWatch. Perbarui Agen SSM ke versi terbaru, atau nonaktifkan opsi log streaming di preferensi Anda."
Kemungkinan kesalahan "versi agen SSM kedaluwarsa".

Untuk memperbarui Agen SSM, kita perlu menavigasi ke Jalankan Perintah di panel kiri layanan AWS Systems Manager .

Tangkapan layar AWS Systems Manager Run Command dashboard dengan bagian, "Cara kerjanya", "Fitur dan Manfaat", "Kasus Penggunaan dan Postingan Blog", "Dokumentasi", dan di sudut kanan atas, "Kelola instans Anda". Bagian itu hanya berisi tombol oranye "Jalankan Perintah".
Langkah 1: Dimulai dengan dasbor "Jalankan Perintah".

Setelah kita berada di sana, kita dapat mengklik tombol oranye "Jalankan Perintah", yang mengarah ke halaman baru di mana kita dapat mengisi beberapa parameter.

Tangkapan layar AWS dengan breadcrumb AWS Systems Manager, Run Command, dan Run a command. Kotak pencarian berlabel "Dokumen perintah" mencantumkan 10 baris (halaman 4 dari lebih dari 5), dengan satu bernama "AWS-UpdateSSMAgent" dipilih. Ini memiliki "Amazon" di kolom "Pemilik" dan "Windows, Linux" di kolom "Jenis platform". Bidang di bagian bawah, "Versi dokumen," memiliki "1 (Default)" dipilih dari daftar drop-down.
Langkah 2: Memilih dokumen perintah.

Kita akan mulai dengan memilih AWS-UpdateSSMAgent dari daftar.

Tangkapan layar bagian AWS berjudul "Target". Kolom pertama, juga disebut "Target", memiliki opsi "Tentukan tag instans", "Pilih instans secara manual" (dipilih), dan "Pilih grup sumber daya". Di bagian bawah adalah kotak pencarian "Instances" tanpa kueri, dengan satu-satunya hasil, "Demo SSM", dicentang. ID instans yang sesuai di baris disalin ke kotak tepat di atas "Instances" dengan tanda X.
Langkah 3: Memilih instans EC2 yang memiliki agen SSM yang membutuhkan pembaruan.

Setelah itu dipilih, kami akan menggulir ke bawah sampai kami melihat bagian "Target". Di sana kita perlu memilih instance EC2 di mana kita ingin memperbarui Agen SSM, lalu tekan tombol "Jalankan" di bagian akhir. Ini akan mengirim kami ke halaman di mana kami dapat memantau kemajuan pembaruan.

Tangkapan layar AWS dengan remah roti "AWS Systems Manager," "Run Command," dan "Command ID" (diikuti dengan GUID). Bagian pertama, "Status perintah", menunjukkan indikator keberhasilan, seperti halnya baris satu-satunya di bagian berikutnya, "Target dan keluaran", yang mencantumkan satu contoh dari sebelumnya. Ada juga dua bagian yang tidak diperluas di bagian bawah, "Deskripsi perintah" dan "Parameter perintah".
Langkah 4: Memantau kemajuan pembaruan kami.

Pembaruan agen tidak akan memakan waktu lebih dari lima menit. Setelah selesai, kita harus dapat membuat sesi kembali di Manajer Sesi.

Pada titik ini, kita harus memulai sesi SSH.

Tangkapan layar AWS dengan ID sesi dan ID instans di atas terminal. Promptnya adalah "sh-4.2$" dan perintah "whoami" dan "pwd" telah dimasukkan, dengan output masing-masing "ssm-user" dan "/usr/bin".
Sesi SSH menggunakan agen SSM melalui AWS Systems Manager Session Manager.

Setelah menjalankan beberapa perintah, mari navigasikan ke grup log CloudWatch Logs (atau bucket S3 kami, tidak ditampilkan) dan konfirmasikan bahwa aktivitas sedang direkam.

Tangkapan layar AWS dengan remah roti "CloudWatch", "CloudWatch Logs", "Grup log", "ssm-session-demo", dan ID sesi dari langkah sebelumnya. Satu-satunya bagian adalah kotak pencarian, "Log peristiwa," dengan baris yang masing-masing memiliki stempel waktu dan pesan berformat JSON. Salah satunya diperluas untuk mengungkapkan JSON yang dicetak cantik dan dengan tombol putih di sebelah kanan berlabel "Salin."
Peristiwa log SSH direkam di CloudWatch Logs.

Kami sekarang memiliki pengaturan, dengan enkripsi saat istirahat diaktifkan, merekam setiap perintah yang dijalankan di mesin Linux kami.

Faktanya, setiap perintah mungkin lebih dari yang kita inginkan: Rahasia apa pun yang diberikan atau dihasilkan selama sesi akan direkam di CloudWatch atau S3 dan dapat dilihat oleh siapa saja yang memiliki izin yang diperlukan. Untuk mencegahnya, kita bisa menggunakan stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; untuk setiap rahasia yang perlu kami berikan selama sesi.

Solusi Logging AWS SSM/SSH Hebat Dengan Peringatan Kecil

Session Manager adalah alat yang berguna untuk mendapatkan akses jarak jauh ke mesin virtual kami di AWS tanpa harus membuka port 22. Faktanya, kami tidak dapat membuat log SSH dengan cara ini jika kami menggunakan penerusan port atau koneksi SSH langsung, sebagai Manajer Sesi catatan dokumentasi.

Meskipun demikian, menggabungkan Pengelola Sesi dengan pencatatan sesi adalah solusi yang andal untuk mengontrol dan memantau aktivitas dalam VM. Selain itu, kami tidak dikenakan biaya untuk menggunakan layanan Session Manager. Kami hanya membayar instans EC2 dan CloudWatch Logs atau bucket S3 kami untuk menyimpan log.

Untuk pembaca yang lebih menyukai tutorial video, saya telah membahas prosedur yang sangat mirip sedikit lebih menyeluruh di YouTube.

Bacaan Lebih Lanjut di Blog Teknik Toptal:

  • Studi Kasus: Mengapa Saya Menggunakan AWS Cloud Infrastructure untuk Produk Saya