Windows Server - AD Üzerinde EFS Yapılandırma Örneği
Merhaba.
Bu konuda, AD ortamınızda EFS'yi (Encrypting File System) nasıl yapılandırabileceğinizi göstereceğim.
EFS, kullanıcı dokümanlarının sertifika ile korunmasını sağlar. Böylece dosyanın sahibi dışında izin verilmeyen kullanıcılar ilgili dosyanın içeriğine erişemeyecektir.
Demo için yukarıdaki ortamı kullanacağım.
Sunucunuza Certification Authority rolünü yüklediğinizde ortamınızdaki sistemler EFS Recovery Agent ve Basic EFS template'lerini kullanarak sertifika edinebilir olacaklardır. Biz de bu anlatımda buradaki template'leri kullanacağız.
EFS'den yararlanmasını istediğiniz bilgisayarları kapsayan bir OU içerisine GPO bağlayarak ya da benim yaptığım gibi tüm sistemlerin etkilenmesi için Default Domain Policy'i editleyerek devam edebilirsiniz.
Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies Encrypting File System poliçesinin özelliklerine girin. File encryption using Encrypting File System (EFS) seçeneğini Allow duruma getirin. Kullanıcılara, EFS'yi kullandıklarında kendi sertifikalarını yedeklemeleri gerektiğini hatırlatmak için kullanıcılarınızın otomatik olarak uyarılmasını sağlayabilirsiniz. Bu özellik için Display key backup notifications when user key is created or changed seçeneğini işaretleyin.
Certificates tab'ından EFS için hangi Certification Template'inin kullanılmasını gerektiğini belirleyebilirsiniz. Ben burada bir değişiklik yapmadan devam edeceğim.
Herhangi bir nedenden dolayı kullanıcı sertifikası kullanılamaz hale gelirse, verileri kurtarabilmek için Domain Administrator hesabını Recovery Agent olarak yapılandıracağım. Bunun için Encrypting File System'a sağ tıklayıp Create Data Recovery Agent'a tıklıyorum.
İsterseniz Issued By kısmında Self-Signed olarak gözüken Recovery Agent sertifikasını silebilirsiniz.
user1@vatanci.int kullanıcısı ile Win10 Ent 1 üzerinde test dokümanı oluşturuyorum.
Bu dosyanın bulunduğu klasörün özelliklerine girip Advanced butonuna tıklayıp Encrypt contents to secure data seçeneğini işaretliyorum.
Bu ayarı tüm alt dosyalara ve klasörlere uyguluyorum.
Certification Authority konsolunda User1 kullanıcısının Basic EFS template'ini kullanarak bir sertifika edindiğini göreceksiniz.
EFS ile korunan dosyanın özelliklerine girip Advanced > Details'e tıkladığımda bu dosyaya User1'in erişebileceğini, Recovery Policies'a göre Recovery Account'unun VATANCI\Administrator olduğunu görmekteyim.
İsterseniz (dosyaya erişim izni olan biri olarak) bu dosyaya diğer kullanıcıların da erişebilmesini sağlayabilirsiniz. Bunun için "diğer kullanıcıların" bu makine üzerinde daha önceden oturum açmış ve EFS'i en az 1 kez kullanmış olmaları gerekmektedir. Bunun nedeni, ilgili kullanıcıların EFS sertifikalarının local makine üzerinde bulunması gerektiğinden kaynaklanır. Yani local makine üzerinde sertifikası bulunmayan bir kullanıcıya erişim izni verememekteyiz.
Bu dosyaya erişim izni olmayan başka bir account üzerinden erişmeye çalıştığımda iznimin olmadığına dair bir uyarıyla karşılaşıyorum. Yani EFS is working fine. :-)
Şimdi biraz beyin yakalım.
Win10 Ent 1 makinesi üzerinde administrator@vatanci.int ile login olup dosyaya erişmeye çalışıyorum ama o da ne, gerekli iznimin olmadığına dair uyarı alıyorum. Oysa bu hesap Recovery edebilir durumda olmalıydı.
Bunun nedeni makine üzerinde File Recovery sertifikamızın bulunmuyor olmasıdır.
Bu durumu aşmak için DC üzerinden ilgili sertifikayı Export edip Win10 Ent 1 üzerinde bu sertifikayı User tarafına Import ediyorum.
Ve dosyaya erişimim mümkün oluyor. Peki buradaki süreç nasıl işliyor?
Dosya kriptolanırken erişim izni bulunan kullanıcıların sertifikalarındaki thumbprint bilgileri dosyanın özniteliklerine yazılır. Eğer dosyaya erişmek isteyen kişide bu thumbprint'i içeren geçerli bir sertifika mevcutsa dosyaya erişebilir.
Bir başka beyin yakma durumuna bakalım.
Dosyaya erişim izni bulunan User1'in serfikasını on-hold duruma getiriyorum. Yani geçersiz yapıyorum. Bu durumda ilgili kullanıcının dosyaya artık erişemeyeceğini umuyorum.
Ama dosyaya erişmeye devam ediyor. Peki bu nasıl mümkün oldu?
Bunun nedeni, ilgili sertifikamız Revocation durumunu herhangi bir OCSP (Online Certificate Status Protocol) üzerinden check edemiyor olmasından kaynaklanmakta. Demo için hazırladığım ortamda OCSP yapılandırmasını tamamlamadığımdan dolayı sertifikamız geçerli olup olmadığını kontrol edemediğinden ilgili kullanıcının dosyaya erişim izni devam ediyor. Yani sertifikalarımız online bir hizmet üzerinden ve DC makinesi tarafından dağıtılırken aslında offline olarak çalışıyorlar. Bunu aşmak için OCSP yapılandırmasını tamamlamanız gerekmekte.