Güvenlik modeli ve IEC 62443-3-3
Bu sayfa YTCC'nin güvenlik modelini anlatır ve onu IEC 62443-3-3'ün bir SCADA sistemi için en önemli sistem gereksinimleriyle (SR) karşılaştırır. Bir tesisin güvenlik değerlendirmesine yardımcıdır, bir sertifika değildir.
Güvenlik modeli
- Proje başına tek kimlik otoritesi. Proje sunucusu her projenin kullanıcılarını, profillerini ve politikalarını tutar ve oturum belirteçlerini imzalar. Ağ geçidi, alarm servisi ve konfigürasyon servisi her oturumu ona doğrulatır; yetkiler belirteçten değil şimdiki konfigürasyondan okunur, böylece değişen bir profil en geç 10 saniyede geçerli olur.
- Komutlar ve değişiklikler sunucuda denetlenir. Komutlar, alarm onayları, konfigürasyon değişiklikleri ve kullanıcı yönetimi, ekran ne gösterirse göstersin sunucu tarafından kabul ya da reddedilir.
- Hata durumunda kapalı. Sunucu kimlik doğrulama konfigürasyonunu okuyamazsa ya da kimlik otoritesine ulaşamazsa istekler izin verilmek yerine reddedilir. Aynısı kilitler ve sorumluluk alanları için de geçerlidir.
- Oturumlar. Oturum belirteci 15 dakika geçerlidir; tarayıcı oturum açık kaldıkça onu arka planda yeniler. Arayüz etkinliği olmayan oturumu, bir dakika önce uyararak 30 dakika sonra bitirir. Çıkış oturumu iptal eder.
Yeni projenin durumu olan kimlik doğrulaması kapalıyken herkes anonimdir ve her eylem açıktır. Proje sahada kullanılmadan önce kimlik doğrulamasını açın; bkz. Kimlik doğrulamayı açma.
Karşılanan gereksinimler
| Gereksinim | YTCC nasıl karşılar |
|---|---|
| SR 1.1 İnsan kullanıcının tanımlanması ve kimlik doğrulaması | Proje başına kişisel kullanıcı hesapları; her komut, onay ve değişiklik girişli kullanıcıya bağlıdır |
| SR 1.3 Hesap yönetimi | Kullanıcılar ve profiller proje başına sistem yöneticisi root tarafından yönetilir; proje kullanıcıları yalnız işletir. Değişiklikler kullanıcı denetim kaydındadır |
| SR 1.7 Parolaya dayalı kimlik doğrulamanın gücü | Parola politikası: en az uzunluk (varsayılan 8), büyük harf ve rakam, 5 parolalık geçmiş, kullanıcı adına eşit olamaz; bcrypt özeti olarak saklanır |
| SR 1.11 Başarısız giriş denemeleri | Beş başarısız giriş hesabı 15 dakika kilitler |
| SR 1.12 Sistem kullanım bildirimi | İsteğe bağlı giriş bildirimi; onay istenirse parola ancak bildirim onaylandıktan sonra denetlenir |
| SR 2.1 Yetkilendirmenin uygulanması | Profil başına yetkiler; komutlar, onaylar, konfigürasyon değişiklikleri ve kullanıcı yönetimi her istekte sunucuda denetlenir; kontrol için sorumluluk alanları |
| SR 2.5 Oturum kilidi | Arayüz oturumu boşta kalma süresinden sonra bitirir |
| SR 2.8 Denetlenebilir olaylar | Kullanıcı denetim kaydı, konfigürasyon denetimi, olay listesi ve komut kaydı; bkz. Denetim kayıtları |
| İkili onay | İkinci kullanıcı onaylı kritik komutlar; gerekçeyle ve varsayılan olarak ikinci kullanıcıyla kilit aşma |
Tesis işletmecisinin eklediği
| Konu | Yapılacak |
|---|---|
| Varsayılan hesaplar | Konfigürasyon editöründe kimlik doğrulamasını açmak parolası kullanıcı adı olan dokuz hesap oluşturur (örneğin admin / admin). Tesis işletmeye alınmadan önce kişisel hesaplar oluşturun ve varsayılan hesapları devre dışı bırakın. Silmek yerine devre dışı bırakın: kimlik doğrulamayı kapatıp yeniden açmak silinen varsayılan hesabı, parolası kullanıcı adı olarak yeniden oluşturur |
| İstasyonlara erişim | Operatör istasyonlarına ağ erişimini sınırlayın |
| Birden çok projenin hesapları | Hesaplar proje başınadır; projelerin hesap listelerini tutarlı tutun |
| İletişim | Sunucuyu ve istemcileri korunan bir ağda tutun ya da YTCC'nin önüne şifreleyen bir ters vekil sunucu koyun |
| Denetim bilgisi | Sunucuya erişimi kısıtlayın ve günlükleri korunan bir yerde tutun |
| İstasyona göre kısıtlama | İstasyon başına ağ kuralları kullanın; canlı veri sunucusu kendi portunda yalnız listelenen istemci adreslerini, web arayüzü de yalnız allow listesindeki ağları kabul edebilir (bkz. Güvenlik sertleştirme) |
| Gizli ekranlar | Gizli bilgi için sayfa erişimini kullanmayın; bkz. Sayfa erişimi |
Ağ tarafı için bkz. Güvenlik sertleştirme kontrol listesi.