AWS SSM Kullanarak SSH Günlüğü ve Oturum Yönetimi

Linux'ta bir SSH günlüğü tutmak için özel araçlar veya komut dosyaları ayarlamak sıkıcı ve hataya açık olabilir.

Mühendisler, kullanıcı etkinliğini günlüğe kaydetmek için rootsh , screen veya başka bir yardımcı programı kullanabilir, ancak kullanıcı izinleri doğru ayarlanmazsa, yetenekli bir kullanıcı izlerini kapatmak için denetim günlüklerini silebilir. Başka bir seçenek de, günlük kaydını çekirdek düzeyinde ayarlamak olabilir, ancak bunun için gereken uzmanlık o kadar yaygın değildir.

Neyse ki, tek bir Linux komutu bile yazmadan kullanıcı etkinliğini kaydetmenin bir yolu var! Şu hizmetlere ihtiyacımız olacak:

• EC2
• IAM (Kimlik ve Erişim Yönetimi)
• KMS (Anahtar Yönetim Hizmeti)
• CloudWatch Günlükleri (ve/veya S3)
• AWS Systems Manager (eski adıyla SSM)

Her birinin nasıl kurulacağını görelim.

EC2 ve IAM

Bir EC2 bulut sunucusunu başlatmak normalde oldukça kolaydır, ancak başlatma sırasında yapılması gereken önemli bir görev vardır: Bulut sunucumuza bir IAM rolü eklememiz gerekir, aksi takdirde bunun sonunda ayrıntılı olarak açıklanan beklenen sonuçları elde edemeyiz makale.

EC2 bulut sunucumuzla ilişkilendirdiğimiz IAM rolü, yerleşik AmazonSSMManagedInstanceCore politikasına ve ayrıca bu politikaya (satır içi veya müşteri tarafından yönetilen olarak eklenir) sahip olmalıdır:

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

IAM rolünün yanı sıra genellikle bu EC2 bulut sunucusu yapılandırmasını kullanırız:

• İşletim sistemi Amazon Linux 2'dir, çünkü varsayılan olarak AWS Systems Manager Agent (SSM Agent) yüklü olarak gelir. (Ayrıca bir seçenek olan Ubuntu dağıtımları da öyle.)
• Örnek Türü t3.micro'dur (ancak herhangi bir tür işe yarar).
• Bu alıştırma için açık bir SSH bağlantı noktasına ihtiyacımız olmadığından, AWS'nin VPC'ye atadığı varsayılan Güvenlik Grubu çalışacaktır.

EC2 örneğinin açılmasını beklemeden KMS kurulumuna başlayabiliriz.

KMS

CloudWatch'a gönderilen tüm oturum günlüklerinin şifreli olarak saklanmasını istiyorsak bir KMS anahtarına ihtiyacımız var. KMS servisine gidelim ve bir anahtar oluşturalım.

Anahtarın AWS hesabının kök kullanıcısı dışındaki kullanıcılar tarafından yönetilebilmesi için bir yönetici atamanızı öneririz, ancak başkalarının erişime ihtiyacı yoksa 3. Adımı atlayabiliriz.

Burada kilit yönetici olarak IAM kullanıcısını "yönetici" seçtik, ancak herhangi bir kullanıcıyı veya rolü seçmekte özgürüz. Yönetici için anahtar silme iznini devre dışı bırakmayı da seçebiliriz.

Bu anahtarın yalnızca CloudWatch Logs hizmeti tarafından SSH günlük şifreleme ve şifre çözme işlemleri için kullanılmasını istediğimiz için bu anahtara herhangi bir kullanıcı atamayacağız.

Gözden Geçirme sayfasında, CloudWatch Günlüklerinin anahtarı kullanma izinlerini içermediğinden, KMS tarafından oluşturulan anahtar politikasını değiştirmemiz gerekecek. Bunu şu politikayla değiştireceğiz:

 { "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:*" } } } ] }

Tüm yer tutucuları değiştirdiğinizden emin olun:

• ACCOUNT_ID , AWS hesap kimliğimiz olur.
• USERNAME , Adım 3'te seçilen yönetici kullanıcı adı olur. Bu adımdan vazgeçersek, burada ikinci ifade bloğunu kaldırırız ( "Sid": "Allow access for Key Administrators" ).
• REGION , hizmetleri dağıttığımız bölgesel tanımlayıcı kod haline gelir (ör. us-west-1 ).

Bununla, KMS gitmeye hazır.

CloudWatch Günlük Grubu

Ardından, SSM Agent'ın SSH oturum günlüklerini gönderebileceği bir CloudWatch Log grubuna (ve/veya bir S3 kovası - aşağıya bakın) ihtiyacımız var. Hadi onu oluşturalım.

KMS anahtarı ARN alanına dikkat edin: AWS, KMS bölümünün 5. Adımında anahtar oluşturulduktan sonra burada gereken değeri bize sağlar.

(CloudWatch Logs hizmetinin anahtarı kullanmasına izin vererek doğru politikayı daha önce KMS anahtarımızla ilişkilendirmediysek, bu noktada KMS anahtarıyla ilgili bir hata alırız.)

 { "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": "*" } ] }

Artık günlükleri (CloudWatch Günlükleri, bir S3 kovası veya her ikisini) depolamak için bir yer oluşturduğumuza göre, SSH oturumlarından yararlanmaya hazırız.

AWS Sistem Yöneticisi Oturum Yöneticisi

Bu, SSH oturumu izleme ve günlüğe kaydetme için Linux makinemize güvenli erişimi yapılandırdığımız son önemli adımdır. Oturum Yöneticisi panosunda başlayacağız.

Kontrol panelinde, oturum günlüğünü etkinleştirmek için sağ üstteki "Bir oturum başlat" kutusundaki beyaz "Tercihleri ​​Yapılandır" düğmesine tıklayın.

Tercihler sayfasında, keşfedebileceğimiz birden fazla bölüm bulacağız, ancak Linux makinemizde neler olduğunu hızlıca görmemizi sağlamak için SSH oturum günlüklerini CloudWatch veya S3'e aktarmaya odaklanacağız.

“CloudWatch logging” bölümünden hemen sonra, kovayı seçebileceğimiz bir “S3 logging” bölümü var.

SSH günlüğü yapılandırıldıktan sonra, Linux makinemize SSH uygulayabilir ve etkinliğin yakalanıp yakalanmadığını görmek için bazı komutlar yürütebiliriz.

Öyleyse, bir oturum başlatalım. Aynı sayfada, bir oturum başlatabileceğimiz bir “Oturumlar” sekmesi bulacağız. "Oturumu başlat" düğmesine tıklamak, bize bir oturum başlatabileceğimiz EC2 makinelerinin bir listesini verecektir:

EC2 Linux örneğimizi listede görmüyorsak, çalışır durumda olup olmadığını ve daha önce açıkladığımız IAM izinlerine sahip olup olmadığını kontrol etmeliyiz.

Bir SSM Aracısının İşlenmesi "Akış Günlüklerini Desteklemiyor" Hatası

EC2 makinemizde kurulu SSM Agent sürümünün CloudWatch günlüklerinin akışını desteklemediğini söyleyen bir hata almamız durumunda endişelenmeyin. Bunu düzeltmenin acısız bir yolu var.

SSM Agent'ı güncellemek için AWS Systems Manager hizmetinin sol panelindeki Run Command'a gitmemiz gerekiyor.

Oradayken, bazı parametreleri doldurabileceğimiz yeni bir sayfaya giden turuncu “Komut Çalıştır” düğmesine tıklayabiliriz.

Listeden AWS-UpdateSSMAgent'ı seçerek başlayacağız.

Bu seçildiğinde, "Hedefler" bölümünü görene kadar aşağı kaydıracağız. Orada SSM Agent'ı güncellemek istediğimiz EC2 örneğini seçmemiz ve sonunda "Çalıştır" düğmesine basmamız gerekiyor. Bu bizi güncellemenin ilerlemesini izleyebileceğimiz bir sayfaya gönderecektir.

Aracı güncellemesi beş dakikadan fazla sürmemelidir. Bu yapıldıktan sonra, Oturum Yöneticisinde bir oturum oluşturabilmeliyiz.

Bu noktada bir SSH oturumu başlatmış olmalıyız.

Birkaç komut yürüttükten sonra, CloudWatch Logs günlük grubuna (veya gösterilmeyen S3 kovamıza) gidelim ve etkinliğin kaydedildiğini onaylayalım.

Artık, Linux makinemizde başlatılan her komutu kaydeden, hareketsiz şifrelemenin etkin olduğu bir kurulumumuz var.

Aslında, her komut istediğimizden daha fazla olabilir: Oturum sırasında sağlanan veya oluşturulan herhangi bir sır, CloudWatch veya S3'e kaydedilecek ve gerekli izinlere sahip herkes tarafından görülebilecek. Bunu önlemek için stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; oturum sırasında sağlamamız gereken her sır için.

Küçük Uyarılarla Harika Bir SSM/SSH AWS Günlük Kaydı Çözümü

Session Manager, 22 numaralı bağlantı noktasını açmak zorunda kalmadan AWS'deki sanal makinelerimize uzaktan erişim elde etmek için kullanışlı bir araçtır. Aslında, Oturum Yöneticisi olarak bağlantı noktası yönlendirme veya doğrudan bir SSH bağlantısı kullanırsak SSH günlüklerini bu şekilde oluşturamayız. dokümantasyon notları.

Bununla birlikte, Session Manager'ı oturum günlüğüyle birleştirmek, VM'lerdeki etkinliği kontrol etmek ve izlemek için sağlam bir çözümdür. Ayrıca, Session Manager hizmetini kullanmak için ücretlendirilmiyoruz. Yalnızca EC2 bulut sunucumuz ve CloudWatch Logs veya günlükleri depolamak için bir S3 paketi için ödeme yaparız.

Video eğitimlerini tercih eden okuyucular için YouTube'da çok benzer bir prosedürü biraz daha ayrıntılı olarak ele aldım.

Toptal Mühendislik Blogunda Daha Fazla Okuma:

• Örnek Olay: Ürünlerim İçin Neden AWS Bulut Altyapısını Kullanıyorum?