Genel olarak, saldırı yüzeyinizi küçültmek her zaman en iyisidir. Hiçbir sistem mükemmel değildir ve devre dışı bırakma protokolünüz hem programatik hem de olası insan hatası nedeniyle bir istisna olmayacaktır.

Risk 1: Feshedilen tüm çalışan hesaplarınızın, örneğin veritabanındaki çalışan tablosundaki rollerini (veya nasıl depolandıklarını) değiştirerek uygun şekilde devre dışı bırakıldığını varsayalım. Bu varsayımsal senaryoda, yönetici hesabınızın güvenliği ihlal edilmiştir. Akıllı bir saldırgan, geçmişte feshedilmiş bir çalışanın hesabını yeniden etkinleştirmek için yönetici hesabını kullanabilir ve bu hesabı sistemde kötü amaçlı etkinlik yürütmek için kullanabilir. Bunu yaparak, izinsiz giriş tespit sistemleri tarafından keşfedilme olasılıkları daha düşüktür (yani yönetici her zaman Teksas, ABD'den oturum açmıştır, ancak birden bire bir yönetici Brezilya'da mı?). Bu, saldırı yüzeyini artırabilir ve potansiyel olarak saldırgana daha fazla güç verebilir. Asla iyi bir şey değil.

Risk 2: İnsan hatası var. Ya bir gün hala geçerli bir çalışan hesabını yanlışlıkla devre dışı bırakır ve yeniden etkinleştirmek istediğinizde Alexander yerine Alex yazarsanız ve şimdi feshedilmiş bir çalışan hesabını yeniden etkinleştirirseniz? Ya da belki bir hesabı yeniden etkinleştirmek niyetinde bile değildiniz ama bir gün bilgisayarınız donduğunda ve yanıt almak için herhangi bir şeye tıklamak için farenizi öfkeyle spam gönderirken yeniden etkinleştirme bayrağına tıkladınız mı?

olası değil ama neden risk alalım?

Sisteminizin çalışması için sistemde hala var olan hesaplara dayanan karmaşık bir denetim izine ihtiyaç duymuyorsa (yani, kullanıcının adını ve eylemi kullanıcı bilgilerine aktif olarak erişir ancak yine de aktif olarak erişir), bu şişkin verileri sisteminizde bırakmak için iyi bir neden yoktur.

Bir şirketten ayrıldıktan sonra (geçmişte kooperatif olarak çalışırken çeşitli şirketlerde sık sık vakit geçirdim) hala hesaplarıma giriş yapıp yapamayacağımı ve daha sık kontrol ederim. Öyle ya da böyle yapabilirim.

Her zaman siber güvenlik tarafında hata yaparım.

Öncelikle, "adres" den daha doğru kelimeler olduğundan "riski ele almak" terimini kullanmaktan hoşlanmıyorum. Bunun risk yönetiminde yaygın olarak kullanılan bir terim olduğunu biliyorum, ancak muhtemelen yanlış anlaşılacağını düşünüyorum, bu yüzden bundan kaçınmayı tercih ederim.

Her neyse, devre dışı bırakılan bir hesabın adreslerini kaldırmanın bir güvenlik riski yok. Ancak, yanlış soruyu sorduğunuza inanıyorum.

Bu, "devre dışı bırakılmış bir hesap" ile ne demek istediğinize bağlıdır.

Devre dışı bırakılmış bir hesap, arka arkaya bir satır kadar basit olabilir 2 sütunlu veritabanı, bir tam sayı olan bir birincil anahtar kullanıcı kimliği ve "TRUE" olarak ayarlanmış bir enum devre dışıdır . Devre dışı bırakılan bu hesabı silmek bir risk oluşturur mu? Öyle olduğunu sanmıyorum.

Ancak yelpazenin diğer ucunda, devre dışı bırakılan hesap, kredi kartı numaraları, şifrelenmemiş şifreler, ehliyet fotoğrafı, sosyal güvenlik numarası vb. > devre dışı bırakıldı "TRUE" olarak ayarlandı.

Senaryonuzda "devre dışı bırakılmış hesap" tam olarak nedir?

Genel olarak, devre dışı bırakılan hesapları asla silmemenizi tavsiye ederim. hesabı "devre dışı bırakma" noktasında hassas bilgileri kaldırmayı düşünün. Dolayısıyla, bir kullanıcı hesabını devre dışı bırakır ve ardından yeniden etkinleştirirse, kart numaralarını tekrar eklemesi, telefon numarasını yeniden doğrulaması vb. Gerekir. Yani temelde tüm bayrakları varsayılan konumlarına ayarlamak ve yalnızca hassas olmayan bilgileri saklamak.

Devre dışı bırakılan hesapları tutmanın değeri vardır. Bugüne kadar kaç kullanıcının kaydolduğuna dair kesin bir siciliniz var ve bazı bilgilerini çeşitli amaçlar için saklamayı düşünebilirsiniz. Bir kullanıcı kaydolursa, telefon numarasını doğrularsa, sisteminiz tarafından kara listeye alınır / yasaklanır, ardından hesabını devre dışı bırakır (ve "devre dışı bırakma" sisteminiz telefon numarasını veya telefon numarası dahil tüm satırını kaldırır), sonra imzalayabilir başka bir e-posta adresiyle tekrar yukarı çıkın ve telefon numarasını yeniden etkinleştirin ve potansiyel olarak kara listeyi aşın (kara listeniz bir sütun yasaklanmışsa).

Bu nedenle, devre dışı bırakılan hesaplarınızı kesinlikle saklayın, hassas onlardan alınan bilgiler, özellikle de kullanıcıların sizden silmenizi bekleyeceği, muhtemelen iyi amaçlarla kullanamayacağınız türden bilgiler.

İlk soru şu: Devre dışı bırakma prosedürünüz ne kadar güvenilir? (cevap "% 100" ise, büyük olasılıkla kendinize karşı dürüst olmamanızı öneririm.) Kullanılmayan hesapları kaldırmak, feshedilen çalışanların hesapları devre dışı bırakmayı atlasa bile söz konusu sistemden kaldırılmasını sağlamaya yardımcı olur . Ve eski çalışanların erişime devam etmemesini sağlamak iyi bir güvenlik uygulamasıdır.

Teoride kilitli bir hesap fazla risk teşkil etmemelidir. Birisi devre dışı bırakılmış bir hesabı yeniden etkinleştirirse, yönetici kimlik bilgileriyle zaten ağınızda bulunmaktadır. Ama yine de onlara oyun oynamaları için ek alan vermemek iyi bir şey olacaktır. Bu ihlalin gerçekleştiğini varsayalım. Kötü adamların sadece etkinleştirdikleri arka kapıdan gelmemeleri için işine son verilen tüm çalışanlarınızı gözden geçirmeniz ve hesaplarının tümünün devre dışı bırakıldığından emin olmanız gerekir. oluşturuldu. Ek olarak, devre dışı bırakılan hesapların ayrıştırılması olası saldırı yüzeyini azaltır.

Doğrulanmış bir ortamda, bu hesapların dokümantasyon ve denetim amacıyla etrafta tutulması gerekir. Orada, onları "devre dışı" bir OU'ya taşımak ve bir şekilde yeniden etkinleştirilmediklerinden emin olmak için her gece onlara karşı kontrol yapmak mantıklıdır.

TL / DR: Bu hesapları ortalıkta tutmak için iyi bir neden olmadıkça, onları kaldırmak daha mantıklıdır.

Hangi kullanıcı hesaplarından bahsediyorsunuz?

Onları saklamanız gereken kolay bir örnek: Unix sunucunuzdaki hesaplar.

Hesabı tutmazsanız kazanırsınız Bir yerde bulduğunuz hiçbir dosyayı, silinmiş bir kullanıcıya aitse ilişkilendiremezsiniz. Kullanıcı kimliği (ad değil, sayısal olan) yeni bir hesap verildiğinde, yeni kullanıcı eskisinin kalan dosyalarına bile erişebilir.

Çoğu yanıt, bu sorunun güvenlik yönüne odaklanır ve haklı olarak, bu sitenin güvenliğe odaklandığı düşünüldüğünde. Ancak bunun başka bir yönü daha var, ihtiyacınız olmayan verileri tutmanın getirdiği yasal sorunlar.

Artık kullanılmayan hesapları bırakmak, tonlarca kullanılmamış ve muhtemelen düzenlenmemiş veri bırakır. Bu sadece hedef olarak sistemin çekiciliğini arttırmakla kalmaz, aynı zamanda yazılımın şirketini / sahibini ülkeye bağlı olarak bazı önemli hukuki sıkıntılara sokabilir. Birisi erişim kazandıkları verileri sızdırır veya satarsa, şirket, hassas verilerin kaydedildiği her sızan hesabın verilerinden sorumlu olur (çoğu ülkede).

Güvenlik olmamalıdır ' sadece önlemeyi değil, aynı zamanda hafifletme ve hasar kontrolünü de içerir. Veri ihlalleri ve sızıntıları söz konusu olduğunda şirket tamamen yasalarla kapsanmış olsa bile, sistemi olabildiğince çekici hale getirmek kesinlikle iyi bir uygulamadır. Bir sisteme kötü niyetli kazanç için saldırmayı ciddi olarak düşünen herkes, [Elde edilen veriler: Zaman / çaba gerekli] oranına göre hedef seçiyor olacaktır. Bir sistemdeki veri miktarını en aza indirmek, bir saldırgan için zorluğu katlanarak artırmaktan çok daha kolaydır.

Kendi çözümümde, daha önce atanan kimliklerin (kullanıcı adları, POSIX-Kimlikleri) yeniden kullanılmasını önlemek için kullanıcı hesapları asla silinmiyor.

Ancak kullanıcı hesaplarını devre dışı bırakmak için iki farklı durum vardır:

1. devre dışı bırakıldı: Hesap geçici olarak devre dışı bırakıldı, sözde bölge yöneticileri tarafından görülmeye devam ediyor ve bölge yöneticisi tarafından yeniden etkinleştirilebilir.
2. arşivlendi: Hesap nihayet devre dışı bırakıldıgizlilik düzenlemeleri nedeniyle bazı özellikler çıkarılır.Hesaplar artık bölge yöneticileri tarafından görünmez ve bu durumdan yeniden etkinleştirilemez.

Ayrıca Æ-DIR’ın aeStatus özniteliğinin açıklamasına da bakın.