Sürücü geliştiricileri için Windows güvenlik modeli

Windows güvenlik modeli güvenli hale getirilebilir nesneleri temel alır. İşletim sisteminin her bileşeni, sorumlu olduğu nesnelerin güvenliğini sağlamalıdır. Bu nedenle sürücülerin cihazlarının ve cihaz nesnelerinin güvenliğini koruması gerekir.

Bu konu başlığında, Windows güvenlik modelinin çekirdek modu sürücülerine nasıl uygulandığı özetlemektedir.

Windows güvenlik modeli

Windows güvenlik modeli öncelikle nesne başına hakları temel alır ve az sayıda sistem genelinde ayrıcalıklara sahip olur. Güvenli hale getirilebilen nesneler arasında işlemler, iş parçacıkları, olaylar ve diğer eşitleme nesnelerinin yanı sıra dosyalar, dizinler ve cihazlar bulunur.

Her nesne türü için genel okuma, yazma ve yürütme hakları, nesneye özgü ayrıntılı haklara dönüştürülür. Örneğin, dosya ve dizinler için olası haklar arasında dosyayı veya dizini okuma veya yazma hakkı, genişletilmiş dosya özniteliklerini okuma veya yazma hakkı, dizinde dolaşma hakkı ve nesnenin güvenlik tanımlayıcısını yazma hakkı yer alır.

Güvenlik modeli aşağıdaki kavramları içerir:

• Güvenlik tanımlayıcıları (SID)
• Erişim belirteçleri
• Güvenlik tanımlayıcıları
• Erişim Denetim Listeleri (ACL'ler)
• Ayrıcalıklar

Güvenlik Tanımlayıcıları (SID)

Güvenlik tanımlayıcısı ( sorumlu olarak da adlandırılan SID), bir kullanıcıyı, grubu veya oturum açma oturumsunu tanımlar. Her kullanıcı, oturum açma sırasında işletim sistemi tarafından alınan benzersiz bir SID'ye sahiptir.

SID'ler işletim sistemi veya etki alanı sunucusu gibi bir yetkili tarafından verilir. Bazı SID'ler iyi bilinir ve adların yanı sıra tanımlayıcılara sahiptir. Örneğin, SID S-1-1-0, Herkesi (veya Dünyayı) tanımlar.

Erişim belirteçleri

Her işlemin bir erişim belirteci vardır. Erişim belirteci, işlemin tam güvenlik bağlamını açıklar. Kullanıcının SID'sini, kullanıcının ait olduğu grupların SID'sini ve oturum açma oturumunun SID'sini ve kullanıcıya verilen sistem genelindeki ayrıcalıkların listesini içerir.

Varsayılan olarak, bir işlemin iş parçacığı güvenlik nesnesiyle etkileşimde bulunduğunda, sistem o işlem için birincil erişim belirtecini kullanır. Ancak, bir iş parçacığı bir müşteri hesabının kimliğine bürünebilir. Bir iş parçacığı kimliğe büründüğünde, kendi birincil belirtecine ek olarak kimliğe bürünülen bir belirteci daha bulunur. Kimliğe bürünme belirteci, iş parçacığının benimsediği kullanıcı hesabının güvenlik bağlamını açıklar. Kimliğe bürünme özellikle Uzaktan Yordam Çağrısı (RPC) işleminde yaygındır.

İş parçacığı veya işlem için kısıtlanmış bir güvenlik bağlamı açıklayan erişim belirteci, kısıtlanmış belirteç olarak adlandırılır. Kısıtlanmış bir belirteçteki SID'ler, korunabilir nesnelere yalnızca erişimi reddedecek şekilde ayarlanabilir, izin vermek için değil. Ayrıca belirteç, sistem genelinde sınırlı sayıda ayrıcalık tanımlayabilir. Kullanıcının SID ve kimliği aynı kalır, ancak işlem kısıtlanmış belirteci kullanırken kullanıcının erişim hakları sınırlıdır. CreateRestrictedToken işlevi kısıtlanmış bir belirteç oluşturur.

Güvenlik tanımlayıcıları

Her adlandırılmış Windows nesnesinin bir güvenlik tanımlayıcısı vardır; bazı adsız nesneler de bunu yapar. Güvenlik tanımlayıcısı, nesnenin sahibini ve grup SID'lerini ve ACL'lerini açıklar.

Bir nesnenin güvenlik tanımlayıcısı genellikle nesneyi oluşturan işlev tarafından oluşturulur. Bir sürücü bir cihaz nesnesi oluşturmak için IoCreateDevice veya IoCreateDeviceSecure yordamını çağırdığında, sistem oluşturulan cihaz nesnesine bir güvenlik tanımlayıcısı uygular ve nesne için ACL'leri ayarlar. Çoğu cihaz için, ACL'ler cihaz Bilgileri (INF) dosyasında belirtilir.

Daha fazla bilgi için çekirdek sürücüsü belgelerinde Güvenlik Tanımlayıcıları .

Erişim Denetim Listeleri

Erişim Denetim Listeleri (ACL' ler), nesnelere erişim üzerinde ayrıntılı denetim sağlar. ACL, her nesne için güvenlik tanımlayıcısının bir parçasıdır.

Her ACL sıfır veya daha fazla Erişim Denetimi Girdisi (ACE) içerir. Her ACE de bir kullanıcı, grup veya bilgisayar tanımlayan tek bir SID ve bu SID için reddedilen veya izin verilen hakların listesini içerir.

Cihaz nesneleri için ACL'ler

Cihaz nesnesinin ACL'sini üç yoldan biriyle ayarlayabilirsiniz:

• Varsayılan güvenlik tanımlayıcısını cihaz türü için ayarlayın.
• RtlCreateSecurityDescriptor işlevi tarafından program aracılığıyla oluşturulur ve RtlSetDaclSecurityDescriptor işlevi tarafından ayarlanır.
• Cihazın INF dosyasındaki Güvenlik Tanımlayıcısı Tanım Dili'nde (SDDL) veya IoCreateDeviceSecure yordamına yapılan çağrıda belirtilir.

Tüm sürücüler, cihaz nesneleri için ACL'leri belirtmek üzere INF dosyasında SDDL kullanmalıdır.

SDDL, bileşenlerin dize biçiminde ACL oluşturmasını sağlayan genişletilebilir bir açıklama dilidir. SDDL hem kullanıcı modu hem de çekirdek modu kodu tarafından kullanılır. Aşağıdaki şekilde, cihaz nesneleri için SDDL dizelerinin biçimi gösterilmektedir.

Access değeri, izin verilen erişim türünü belirtir. SID değeri, Access değerinin kimlere uygulandığını belirleyen bir güvenlik tanımlayıcısı belirtir (örneğin, bir kullanıcı veya grup).

Örneğin, aşağıdaki SDDL dizesi Sistemin (SY) her şeye erişmesine izin verir ve diğer herkesin (WD) yalnızca okuma erişimine izin verir:

“D:P(A;;GA;;;SY)(A;;GR;;;WD)”

wdmsec.h üst bilgi dosyası, cihaz nesneleri için uygun bir dizi önceden tanımlanmış SDDL dizesini de içerir. Örneğin, üst bilgi dosyası SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX aşağıdaki gibi tanımlar:

"D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)"

Bu dizenin ilk kesimi, çekirdek ve işletim sisteminin (SY) cihaz üzerinde tam denetime izin verir. İkinci segment, yerleşik Administrators grubundaki (BA) herkesin cihazın tamamına erişmesine izin verir, ancak ACL'yi değiştirmesine izin vermez. Üçüncü segment, herkesin (WD) cihazı okumasına veya cihaza yazmasına izin verir ve dördüncü segment de güvenilmeyen koda (RC) aynı hakları verir. Sürücüler, önceden tanımlanmış dizeleri olduğu gibi veya cihaza özgü dizeler için model olarak kullanabilir.

Bir yığındaki tüm cihaz nesneleri aynı ACL'lere sahip olmalıdır. Yığındaki bir cihaz nesnesindeki ACL'lerin değiştirilmesi, tüm cihaz yığınındaki ACL'leri değiştirir.

Ancak, yığına yeni bir cihaz nesnesi eklemek, yeni cihaz nesnesinin (ACL'leri varsa) veya yığındaki mevcut cihaz nesnelerinin ACL'lerini değiştirmez. Sürücü yeni bir cihaz nesnesi oluşturup yığının en üstüne eklediğinde, sürücü sonraki alt sürücüden DeviceObject.Characteristics alanını kopyalayarak yığının ACL'lerini yeni cihaz nesnesine kopyalamalıdır.

IoCreateDeviceSecure yordamı, WD ve SY gibi önceden tanımlanmış SID kullanan SDDL dizelerinin bir alt kümesini destekler. Kullanıcı modu API'leri ve INF dosyaları tam SDDL söz dizimini destekler.

ACL'leri kullanan güvenlik denetimleri

Bir işlem bir nesneye erişim istediğinde, güvenlik denetimleri nesnenin ACL'lerini çağıranın erişim belirtecindeki SID'lerle karşılaştırır.

Sistem, ACE'leri kesin bir yukarıdan aşağıya sırasıyla karşılaştırır ve ilgili ilk eşleşmede durur. Bu nedenle, bir ACL oluştururken, reddetme ACL'lerini her zaman ilgili verme ACL'lerinin üzerine koymanız gerekir. Aşağıdaki örneklerde karşılaştırmanın nasıl ilerleyeceğini gösterilmektedir.

Örnek 1: ACL'yi erişim belirteciyle karşılaştırma

Örnek 1, sistemin bir ACL'yi, bir çağıranın işlemi için erişim belirteciyle nasıl karşılaştırdığını göstermektedir. Çağıranın aşağıdaki tabloda gösterilen ACL'yi içeren bir dosyayı açmak istediğini varsayalım.

Örnek Dosya ACL'si

İzin	SID	Erişim
İzin Ver	Muhasebe	Yazma, silme
İzin Ver	Satışlar	Ekle
Reddet	Hukuki	Ekleme, yazma, silme
İzin Ver	Herkes	Okumak

Bu ACL'de özellikle Muhasebe, Satış, Yasal ve Herkes grupları için geçerli olan dört ACL vardır.

Ardından, istekte bulunan işlemin erişim belirtecinin aşağıdaki sırayla bir kullanıcı ve üç grup için SID içerdiğini varsayalım:

Kullanıcı Jim (S-1-5-21...)

Grup Muhasebesi (S-1-5-22...)

Grup Yasal (S-1-5-23...)

Herkesi Gruplandır (S-1-1-0)

Bir dosya ACL'sini erişim belirteci ile karşılaştırırken, sistem önce dosyanın ACL'sinde Jim kullanıcısı için bir ACE arar. Hiçbiri bulunamazsa, bir sonraki adımda Muhasebe grubu için bir ACE arar. Önceki tabloda gösterildiği gibi, Dosyanın ACL'sinde ilk girdi olarak Accounting grubu için bir ACE görünür, bu nedenle Jim'in işlemine dosyayı yazma veya silme hakkı verilir ve karşılaştırma durdurulur. Eğer Legal grubuna ait ACE, ACL'de Accounting grubuna ait ACE'den önce gelirse, süreç dosyaya yazma, ekleme ve silme erişimi reddedilir.

Örnek 2: ACL'yi kısıtlanmış belirteçle karşılaştırma

Sistem, bir ACL'yi kısıtlanmış bir belirteçle, kısıtlanmış olmayan bir belirteçtekileri karşılaştırdığı şekilde karşılaştırır. Ancak, kısıtlanmış bir belirteçteki bir reddetme SID'i ACL'deki yalnızca Deny ACE ile eşleşebilir.

Örnek 2'de, sistemin bir dosyanın ACL'sini kısıtlanmış belirteçle karşılaştırması gösterilmektedir. Dosyanın önceki tabloda gösterilen ACL ile aynı olduğunu varsayalım. Ancak bu örnekte, işlemin aşağıdaki SID'leri içeren kısıtlı bir belirteci vardır:

Kullanıcı Jim (S-1-5-21...) Reddetmek

Grup Muhasebesi (S-1-5-22...) Reddetmek

Grup Yasal (S-1-5-23...) Erişimi Engelle

Herkesi Gruplandır (S-1-1-0)

Dosyanın ACL'sinde Jim'in SID'i listelenmez, bu nedenle sistem Accounting grubu SID'sine devam eder. Dosyanın ACL'sinde Muhasebe grubu için bir ACE bulunmasına rağmen, bu ACE erişime izin verir. Ancak, işlemin kısıtlanmış belirtecindeki SID ile eşleşmediği için, erişim reddedilir. Sonuç olarak, sistem Hukuk grubu SID'sine ilerler. Dosyanın ACL'sinde Legal grubu için erişimi reddeden bir ACE bulunur, bu nedenle işlem dosyayı yazamaz, ekleyemez veya silemez.

Ayrıcalıklar

Ayrıcalık, bir kullanıcının yerel bilgisayarda sürücü yükleme, saati değiştirme veya sistemi kapatma gibi sistemle ilgili bir işlem gerçekleştirme hakkıdır.

Ayrıcalıklar, nesneler yerine sistemle ilgili görevlere ve kaynaklara uygulandığından ve bir kullanıcıya veya gruba işletim sistemi yerine bir sistem yöneticisi tarafından atandığından erişim haklarından farklıdır.

Her işlemin erişim belirteci, işleme verilen ayrıcalıkların listesini içerir. Ayrıcalıkların kullanımdan önce özel olarak etkinleştirilmesi gerekir. Ayrıcalıklar hakkında daha fazla bilgi için çekirdek sürücüsü belgelerindeki Ayrıcalıklar bölümüne bakın.

Güvenlikle ilgili hata ayıklayıcı komutları

!acl uzantısı bir erişim denetimi listesinin (ACL) içeriğini biçimlendirip görüntüler. Daha fazla bilgi için bkz. Bir Nesnenin ACL'sini belirleme ve !acl.

!token uzantısı, güvenlik belirteci nesnesinin biçimlendirilmiş bir görünümünü görüntüler. Daha fazla bilgi için bkz. !token.

!tokenfields uzantısı, erişim belirteci nesnesinde (TOKEN yapısı) alanların adlarını ve uzaklıklarını görüntüler. Daha fazla bilgi için bkz. !tokenfields.

!sid uzantısı, belirtilen adreste güvenlik tanımlayıcısını (SID) görüntüler. Daha fazla bilgi için bkz. !sid.

!sd uzantısı, belirtilen adreste güvenlik tanımlayıcısını görüntüler. Daha fazla bilgi için bkz. !sd.

Windows güvenlik modeli senaryosu: Dosya oluşturma

Sistem, bir işlem bir dosya veya nesneye tanıtıcı oluşturduğunda Windows güvenlik modelinde açıklanan güvenlik yapılarını kullanır.

Aşağıdaki diyagramda, kullanıcı modu işlemi bir dosya oluşturmaya çalıştığında tetiklenen güvenlikle ilgili eylemler gösterilmektedir.

Önceki diyagramda, kullanıcı modu uygulaması CreateFile işlevini çağırdığında sistemin nasıl yanıt verdiği gösterilmektedir. Aşağıdaki notlar şekildeki daire içine alınmış sayılara başvurur:

1. Kullanıcı modu uygulaması, geçerli bir Microsoft Win32 dosya adı geçirerek CreateFile işlevini çağırır.
2. Kullanıcı modu Kernel32.dll, isteği Ntdll.dll'a geçirir ve bu da Win32 adını Bir Microsoft Windows NT dosya adına dönüştürür.
3. Ntdll.dll, Windows dosya adıyla NtCreateFile işlevini çağırır. Ntoskrnl.exeiçinde G/Ç Yöneticisi NtCreateFile'ı işler.
4. G/Ç Yöneticisi isteği bir Nesne Yöneticisi çağrısına yeniden paketler.
5. Nesne Yöneticisi sembolik bağlantıları çözümler ve kullanıcının dosyanın oluşturulacağı yol için çapraz geçiş haklarına sahip olmasını sağlar. Daha fazla bilgi için bkz . Nesne Yöneticisi'nde güvenlik denetimleri.
6. Nesne Yöneticisi, istekle ilişkili temel nesne türüne sahip olan sistem bileşenini çağırır. Dosya oluşturma isteği için bu bileşen, cihaz nesnelerinin sahibi olan G/Ç Yöneticisi'dir.
7. G/Ç Yöneticisi, kullanıcının cihaza gerekli erişime sahip olduğundan emin olmak için cihaz nesnesinin güvenlik tanımlayıcısını kullanıcının işlemine yönelik erişim belirteciyle karşılaştırarak denetler. Daha fazla bilgi için GÇ Yöneticisi'nde güvenlik denetimleri konusuna bakın.
8. Kullanıcı işlemi gerekli erişime sahipse, G/Ç Yöneticisi bir tanıtıcı oluşturur ve cihaz veya dosya sistemi için sürücüye bir IRP_MJ_CREATE isteği gönderir.
9. Sürücü gerektiğinde ek güvenlik denetimleri gerçekleştirir. Örneğin, istek cihazın ad alanında bir nesne belirtiyorsa, sürücünün çağıranın gerekli erişim haklarına sahip olduğundan emin olması gerekir. Daha fazla bilgi için bkz . Sürücüdeki güvenlik denetimleri.

Nesne Yöneticisi'nde güvenlik denetimleri

Erişim haklarını denetleme sorumluluğu, bu tür denetimleri gerçekleştirebilen en üst düzey bileşene aittir. Nesne Yöneticisi çağıranın erişim haklarını doğrulayabilirse, bunu yapar. Aksi takdirde, Nesne Yöneticisi isteği temel alınan nesne türünden sorumlu bileşene geçirir. Bu bileşen ise erişimi doğrular; bunu yapamıyorsa, isteği sürücü gibi daha düşük bir bileşene geçirir.

Nesne Yöneticisi, ACL'lerde olaylar ve mutex kilitleri gibi basit nesne türlerini denetler. Ad alanı olan nesneler için tür sahibi güvenlik denetimleri gerçekleştirir. Örneğin, G/Ç Yöneticisi, cihaz nesneleri ve dosya nesneleri için tür sahibi olarak kabul edilir. Nesne Yöneticisi bir adı ayrıştırırken bir cihaz nesnesinin veya dosya nesnesinin adını bulursa, yukarıda sunulan dosya oluşturma senaryosunda olduğu gibi adı G/Ç Yöneticisi'ne bırakır. G/Ç Yöneticisi daha sonra erişim haklarını denetler, eğer yapabiliyorsa. Ad bir cihaz ad alanı içindeki bir nesneyi belirtiyorsa, G/Ç Yöneticisi bu adı cihaz (veya dosya sistemi) sürücüsüne devreder ve bu sürücü istenen erişimi doğrulamaktan sorumludur.

G/Ç Yöneticisi'nde güvenlik denetimleri

G/Ç Yöneticisi bir tutamaç oluşturduğunda, nesnenin haklarını süreç erişim belirtecine karşı denetler ve ardından kullanıcıya verilen hakları tutamaçla birlikte depolar. G/Ç Yöneticisi daha sonra G/Ç istekleri geldiğinde, işlemin istenen G/Ç işlemini gerçekleştirme hakkına sahip olduğundan emin olmak için tanıtıcıyla ilişkili hakları denetler. Örneğin, işlem daha sonra bir yazma işlemi isterse, G/Ç Yöneticisi çağıranın nesneye yazma erişimi olduğundan emin olmak için tanıtıcıyla ilişkili hakları denetler.

Kulpların yinelenmesi durumunda, haklar kopyadan kaldırılabilir ancak eklenemez.

G/Ç Yöneticisi bir nesne oluşturduğunda, genel Win32 erişim modlarını nesneye özgü haklara dönüştürür. Örneğin, dosyalar ve dizinler için aşağıdaki haklar geçerlidir:

Win32 erişim modu	Nesneye özgü haklar
GENERIC_OKUMA	ReadData
GENEL_YAZMA	WriteData
GENEL_KOMUT	ReadAttributes
GENEL_TÜM	Tümü

Dosya oluşturmak için, bir işlemin hedef yoldaki üst dizinlere çapraz geçiş haklarına sahip olması gerekir. Örneğin, \Device\CDROM0\Directory\File.txtoluşturmak için bir işlemin \Device, \Device\CDROM0 ve \Device\CDROM0\Directory arasında geçiş yapma hakkı olmalıdır. G/Ç Yöneticisi yalnızca bu dizinler için çapraz geçiş haklarını denetler.

G/Ç Yöneticisi, dosya adını ayrıştırdığında geçiş haklarını denetler. Dosya adı sembolik bir bağlantıysa, G/Ç Yöneticisi bunu tam bir yola çözümler ve sonra kökten başlayarak geçiş haklarını denetler. Örneğin, \DosDevices\D sembolik bağlantısının \Device\CDROM0 Windows NT cihaz adıyla eşlendiğini varsayalım. İşlemin \Device dizinine geçiş hakları olmalıdır.

Daha fazla bilgi için bkz . Nesne Tanıtıcıları ve Nesne Güvenliği.

Sürücüdeki güvenlik denetimleri

İşletim sistemi çekirdeği, aslında her sürücüyü kendi ad alanına sahip bir dosya sistemi olarak ele alır. Sonuç olarak, çağıran cihaz ad alanında bir nesne oluşturmaya çalıştığında G/Ç Yöneticisi işlemin yoldaki dizinlere geçiş haklarına sahip olduğunu denetler.

WDM sürücüleriyle, Cihaz Nesnesi FILE_DEVICE_SECURE_OPEN olarak oluşturulmadığı zaman, G/Ç Yöneticisi ad alanı üzerinde güvenlik denetimleri gerçekleştirmez. FILE_DEVICE_SECURE_OPEN ayarlanmadığında, sürücü ad alanının güvenliğini sağlamakla sorumludur. Daha fazla bilgi için bkz. Cihaz Ad Alanı Erişimini Denetleme ve Cihaz Nesnelerinin Güvenliğini Sağlama.

WDF sürücüleri için FILE_DEVICE_SECURE_OPEN bayrağı her zaman ayarlanır, böylece bir uygulamanın cihazın ad alanı içindeki adlara erişmesine izin vermeden önce cihazın güvenlik tanımlayıcısı denetlenecektir. Daha fazla bilgi için bkz. KMDF Sürücülerinde Cihaz Erişimini Denetleme.

Windows güvenlik sınırları

Birbirleriyle ve farklı ayrıcalık düzeylerindeki kullanıcı modu arayanlarıyla iletişim kurabilen sürücülerin bir güven sınırını aşmış olduğu düşünülebilir. Güven sınırı, daha düşük ayrıcalıklı bir işlemden daha yüksek ayrıcalıklı bir işleme geçen herhangi bir kod yürütme yoludur.

Ayrıcalık düzeylerindeki eşitsizlik ne kadar yüksek olursa, hedeflenen sürücüye veya işleme karşı ayrıcalık yükseltme saldırısı gibi saldırılar gerçekleştirmek isteyen saldırganlar için sınır o kadar ilgi çekicidir.

Tehdit modeli oluşturma işleminin bir parçası, güvenlik sınırlarını incelemek ve tahmin edilmeyen yollar aramaktır. Daha fazla bilgi için bkz . Sürücüler için tehdit modelleme.

Güven sınırını geçen tüm veriler güvenilmez ve doğrulanmalıdır.

Bu diyagramda üç çekirdek sürücüsü ve biri uygulama kapsayıcısında ve diğeri yönetici haklarıyla çalışan bir uygulama olmak üzere iki uygulama gösterilmektedir. Kırmızı çizgiler örnek güven sınırlarını gösterir.

Uygulama kapsayıcısı ek kısıtlamalar sağlayabildiğinden ve yönetici düzeyinde çalışmadığından, güven sınırı bir uygulama kapsayıcısı (çok düşük ayrıcalık işlemi) ile çekirdek sürücüsü arasında olduğundan yol (1) yükseltme saldırısı için daha yüksek bir risk yoludur.

Uygulama yönetici haklarıyla çalıştığından ve doğrudan çekirdek sürücüsüne çağırdığından yol (2) daha düşük bir risk yoludur. Yönetici zaten sistemde oldukça yüksek bir ayrıcalıktır, bu nedenle yöneticiden çekirdeğe olan saldırı yüzeyi saldırganlar için o kadar ilgi çekici bir hedef değildir, ancak yine de dikkate değer bir güven sınırıdır.

Yol (3), bir tehdit modeli oluşturulmazsa atlanacak birden çok güven sınırını geçen bir kod yürütme yolu örneğidir. Bu örnekte, sürücü 1 ile sürücü 3 arasında bir güven sınırı vardır, 1. sürücü kullanıcı modu uygulamasından giriş alır ve doğrudan sürücü 3'e geçirir.

Kullanıcı modundan sürücüye gelen tüm girişlere güvenilmez ve doğrulanmalıdır. Diğer sürücülerden gelen girişler, önceki sürücünün yalnızca basit bir geçiş olmasına bağlı olarak güvenilmeyebilir (örneğin, 1. sürücü tarafından uygulama 1'den alınan veriler, sürücü 1 veriler üzerinde herhangi bir doğrulama yapmadı ve yalnızca sürücü 3'e iletildi). Eksiksiz bir tehdit modeli oluşturarak tüm saldırı yüzeylerini ve güven sınırlarını tanımladığınızdan ve bunlardan geçen tüm verileri doğruladığınızdan emin olun.

Windows Güvenlik Modeli Önerileri

• IoCreateDeviceSecure yordamına yapılan çağrılarda güçlü varsayılan ACL'ler ayarlayın.
• Her cihaz için INF dosyasında ACL'leri belirtin. Gerekirse, bu Erişim Kontrol Listeleri (ACL'ler) sıkı varsayılan ACL ayarlarını gevşetebilir.
• Cihaz ad alanına cihaz nesnesi güvenlik ayarlarını uygulamak için FILE_DEVICE_SECURE_OPEN özelliğini ayarlayın.
• Bu tür erişimden kötü amaçlı olarak yararlanılmadıkça FILE_ANY_ACCESS izin veren IOCTL'leri tanımlamayın.
• FILE_ANY_ACCESS izin veren mevcut IOCTLS'de güvenliği artırmak için IoValidateDeviceIoControlAccess yordamını kullanın.
• Güvenlik sınırlarını incelemek ve tahmin edilmeyen yollar aramak için bir tehdit modeli oluşturun. Daha fazla bilgi için bkz . Sürücüler için tehdit modelleme.
• Ek sürücü güvenliği önerileri için bkz. Sürücü güvenliği denetim listesi.

Ayrıca Bkz.

Cihaz Nesnelerinin Güvenliğini Sağlama

sürücü güvenlik denetim listesi