Gateway akses SSH untuk banyak server

Mengelola beberapa server, lebih dari 90 saat ini dengan 3 devops via Ansible. Semua berfungsi dengan baik, namun ada masalah keamanan raksasa saat ini. Setiap devop menggunakan kunci ssh lokal mereka sendiri untuk mendapatkan akses langsung ke server. Setiap devop menggunakan laptop, dan setiap laptop berpotensi dapat dikompromikan sehingga membuka seluruh jaringan server prod hingga serangan.

Saya mencari solusi untuk mengelola akses secara terpusat, dan karenanya memblokir akses untuk setiap kunci yang diberikan. Tidak berbeda dengan bagaimana kunci ditambahkan ke bitbucket atau github.

Dari atas kepala saya, saya akan menganggap solusi akan menjadi terowongan dari satu mesin, gateway, ke server prod yang diinginkan ... sementara melewati gateway permintaan akan mengambil kunci baru dan digunakan untuk mendapatkan akses ke prod server. Hasilnya adalah kita dapat dengan cepat dan efisien membunuh akses untuk devop apa pun dalam hitungan detik hanya dengan menolak akses ke gateway.

Apakah ini logika yang bagus? Adakah yang melihat solusi di luar sana untuk mengatasi masalah ini?

Itu terlalu rumit (memeriksa apakah kunci memiliki akses ke server prod tertentu). Gunakan server gateway sebagai host lompatan yang menerima setiap kunci yang valid (tetapi dapat dengan mudah menghapus akses untuk kunci tertentu yang menghapus akses ke semua server secara bergantian) dan kemudian menambahkan hanya kunci yang diizinkan untuk setiap server masing-masing. Setelah itu, pastikan Anda dapat mencapai port SSH dari setiap server hanya melalui host melompat.

Ini adalah pendekatan standar.

Insinyur tidak boleh menjalankan secara langsung dari laptop mereka, kecuali ini adalah lingkungan dev / test.

Sebaliknya, miliki server pusat yang menarik runbook dari git. Ini memungkinkan kontrol tambahan (empat mata, tinjauan kode).

Gabungkan ini dengan bastion atau host melompat untuk membatasi akses lebih lanjut.

Netflix mengimplementasikan pengaturan Anda dan merilis beberapa perangkat lunak gratis untuk membantu situasi itu.

Lihat video ini https://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-access atau presentasi ini di https://speakerdeck.com/rlewis/how-netflix-gives- all-its-engineer-ssh-access-to-instance-running-in-production dengan titik inti:

Kami akan meninjau arsitektur SSH bastion kami, yang pada intinya menggunakan SSO untuk mengotentikasi insinyur, dan kemudian menerbitkan kredensial per pengguna dengan sertifikat berumur pendek untuk otentikasi SSH dari bastion menjadi sebuah instance. Kredensial yang berumur pendek ini mengurangi risiko hilangnya mereka. Kami akan membahas bagaimana pendekatan ini memungkinkan kami untuk mengaudit dan secara otomatis mengingatkan setelah fakta, alih-alih memperlambat insinyur sebelum memberikan akses.

Perangkat lunak mereka tersedia di sini: https://github.com/Netflix/bless

Beberapa hal yang menarik bahkan jika Anda tidak menerapkan seluruh solusi mereka:

• mereka menggunakan sertifikat SSH bukan hanya kunci; Anda dapat memasukkan lebih banyak meta-data dalam sertifikat, karenanya memungkinkan banyak kendala per persyaratan dan juga memungkinkan audit yang lebih sederhana
• menggunakan validitas sertifikat yang sangat singkat (seperti 5 menit) (sesi SSH tetap terbuka bahkan setelah sertifikat berakhir)
• menggunakan 2FA juga membuat skrip menjadi sulit dan memaksa pengembang untuk menemukan solusi lain
• submodule tertentu, di luar infrastruktur mereka dan diamankan dengan baik melalui mekanisme keamanan yang ditawarkan oleh cloud tempat ia beroperasi, menangani pembuatan sertifikat secara dinamis sehingga setiap pengembang dapat mengakses host apa pun

SPS OneIdentity (ex-Balabit) adalah hal yang persis Anda butuhkan dalam skenario ini. Dengan alat ini Anda dapat mengelola identitas pengguna pada dasarnya mesin apa pun, melacak perilaku pengguna, memantau dan mengingatkan, dan mengindeks apa pun yang dilakukan pengguna untuk ditinjau nanti.

Saran saya adalah untuk melarang akses SSH dari mesin pengguna.

Sebaliknya Anda harus

1. Host playbook di Git.
2. Ubah "Access server" menjadi server Jenkins.
3. Hibah hanya membutuhkan akses Jenkins ke pengguna devops.
4. Jalankan drama yang dimungkinkan pada Jenkins atas pekerjaan yang dibangun melalui HTTP.
5. Sebagai tindakan keamanan tambahan, nonaktifkan Jenkins CLI jika perlu.

Model pelaksanaan sampel,

1. Plugin Jenkins Ansible: https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin

ATAU

2. Shell klasik - jenis pekerjaan yang dieksekusi. Tambahkan langkah-langkah build Anda secara manual, termasuk checkout git.

Jika Anda terbatas dengan sumber daya server, server Jenkins yang sama dapat meng-host Git (scm-manager) juga, meskipun ada risiko keamanan tambahan jika salah satu mesin pengembang terinfeksi. Anda mungkin dapat mengurangi ini dengan memutuskan koneksi server Jenkins dari internet, dan menyelesaikan dependensi yang dimungkinkan secara lokal.