Etiket: rol tabanlı güvenlik

Dynamics AX 2012 Yetkilendirme Best Practiceleri

Dynamics AX 2012 Yetkilendirme Best Practiceleri

Önceki yazılarda Dynamics AX 2012’ nin yetkilendirme mimarisinde yer alan kavramlar detaylı olarak anlatılmıştı. Bu yazımızda ise yetkilendirme sürecinde izlenmesi gereken best practiceler hakkında bilgi vermeye çalışacağım.

Rol tabanlı güvenlik mimarisinin en güçlü yönlerinden birisi de ayrıcalık ve görev gibi yetkilendirme nesnelerinin farklı görev ve rollerde tekrar tekrar kullanılabilmesidir. AX’ ın standartlarına göre hareket edip ayrıcalık ve görev tanımları doğru kapsamda yapılırsa ciddi anlamda iş gücü ve zaman tasarrufu sağlanacaktır. Aksi taktirde tek rol, tek görev ve tek ayrıcalık tanımlanarak kolaya kaçılırsa her yeni rol ihtiyacında tekrar bütün nesnelere yetki verilecek olan ayrıcalık ve görev tanımlaması yapılmak zorunda kalınacaktır. Aynı zamanda fonksiyon ve ekran bazlı farklı ayrıcalıkların tanımlanması ve bunların mantıksal olarak gruplanarak anlamlı görevlerin oluşturulması yetki atama işlerinin kolayca sistem yönetimi ekiplerine aktarılmasını sağlayacaktır. Bununla birlikte denetim faaliyetlerinde de şeffaflık ve hesap verilebilirlik yönünden tatmin edici sonuçlar ortaya çıkaracaktır.

AX’ ta yetkilendirme sürecinde best practiceleri anlama noktasında standartta gelen rol, görev ve ayrıcalıkları incelemek işleri ciddi anlamda kolaylaştırmaktadır. Standart bir rol ve altındaki görev ve ayrıcalıklar incelenirse AX’ ın nasıl bir yapıda yetkilendirme ile verimli olacağı kolayca anlaşılabilir. Bu yüzden zorlanılan noktalarda standartı incelemek her zaman çözüm hakkında fikir verecektir.

Örneğin standartta yer alan “Maliyet muhasebeci” rolü altında yer alan görevler incelenirse görevlerin nasıl tanımlanması ve ayrıştırması gerektiği anlaşılabilir.

Maliyet_muhasebeci

Yine bu rolün altında yer alan “Maliyet muhasebesi hesaplama durumunu sorgula” görevinin altında yer alan ayrıcalıklar incelenirse ayrıcalık tanımlarının nasıl yapılacağı ve hangi detayda ayrıştırılacağı görülebilir.

görev

Yetkilendirme sürecinde best practiceler açısından dikkat edilmesi gereken en önemli husus standartta yer alan rol, görev ve ayrıcalıkların mümkün olan her yerde kullanılmasıdır. Mümkün olduğu halde standart nesneleri kullanmayıp yeni nesneler oluşturmak gereksiz efor ve nesne kirliliğine yol açacaktır.

İş birimleri tarafından yetkilendirme ile ilgili bir ihtiyaç iletildiğinde ya da bir ekran ya da fonksiyona yetki talebi iletildiğinde izlenmesi gereken adımlar şu şekilde olmalıdır:

1. Bir Nesneye Yetkili Olan Rolleri Bulma

Yetkilendirme nesnelerini oluşturmaya başlamadan önce mevcutta ilgili nesneye yetkili olan bir rol var mı mutlaka kontrol edilmelidir. Mevcutta ihtiyacı karşılayan bir rol var ve rolün o kullanıcıya atanmasında bir sakınca yoksa mevcut rol kullanılmalıdır.

Herhangi bir nesneye yetkili olan rolleri, görev ve ayrıcalık detayında görüntülemek için AOT üzerinde ilgili nesne üzerine sağ tıklanarak Add-Ins > Güvenlik Araçları > İlgili güvenlik rollerini görüntüleme tıklanır.

rolbulma

Açılan formda sorgulanan menu itema hangi yetki nesnelerinin erişebildiği rol, alt rol, görev, ayrıcalık ve erişim tipi detayında listelenir.

sorgulama

Bu sorgulama formu sayesinde kullanıcılardan gelen yetki taleplerinde ilgili nesneye yetkili olan roller görüntülenerek uygun olan bir rol seçip ataması yapılabilir. Aynı şekilde herhangi bir form ya da fonksiyon özellikle bazı kullanıcılar haricinde kısıtlanmak istendiğinde yine bu sorgulama formundan faydalanılarak hangi rollerin erişim yetkisine sahip olduğu görüntülenir ve olmaması gereken bir erişim yetkisi tespit edilirse ilgili güvenlik nesnesi güncellenerek istenen kısıtlama yapılabilir.

2. Mevcut Rol İlgili Kullanıcıya Atanabilir mi Kontrolü

Yetki istenen nesneye erişebilen güvenlik rollerini görüntüledikten sonra ilk olarak mevcutta olan bir rol seçilmeli ve bu rol Security development tool üzerinden test workspaceinde açılarak ya da test ortamında rol kendi kullanıcınıza atanarak açılmalıdır. Rolün erişebildiği menuler, formlar, fonksiyonlar kontrol edilerek yetki talep eden kullanıcıya atanmasında bir sakınca var mı değerlendirilmelidir. Eğer rol kullanıcıya atamak için uygunsa atanmalı ve yeni nesne geliştirilmemelidir. Eğer rolün kullanıcıya atanmasında sakınca var ise bir sonraki kontrol adımına geçilmelidir.

3. Mevcut Görev Mevcut Bir Role Ya da Yeni Bir Role Atanabilir mi Kontrolü

Yetki talep edilen nesneye mevcutta erişebilen bir rol tespit edildi ancak bu rolün kullanıcıya verilmesi uygun görülmediyse rolün altındaki görevler incelenmelidir. Seçilen bir görev kullanıcının hali hazırda sahip olduğu bir role eklenebilir mi kontrol edilmelidir. Görevin içerisinde kullanıcının erişmemesi gereken bir ayrıcalık, form, tablo var mı detaylı olarak analiz edilmelidir. Eğer bir olumsuzluk tespit edilmediyse ve halihazırda sahip olduğu bir role eklenmesi de uygunsa herhangi yeni bir nesne geliştirilmemeli mevcut görev istenen role eklenmelidir.

Tespit edilen görevin mevcut role atanmasında sakınca görülürse yeni bir rol tanımlanmalı ve mevcut görev yeni role atanmalıdır.

Eğer ilgili nesneye erişebilen görevilerin kullanılmasında sakınca var ise bir sonraki kontrol adımında geçilmelidir.

4. Mevcut Ayrıcalık Mevcut Bir Göreve Ya da Yeni Bir Göreve Atanabilir mi Kontrolü

Yetki talep edilen nesneye mevcutta erişebilen bir görev tespit edildi ancak bu görevin mevcut ya da yeni bir role eklenmesi uygun görülmediyse görevin altındaki ayrıcalıklar incelenmelidir. Seçilen bir ayrıcalık kullanıcının hali hazırda sahip olduğu rollerin altındaki görevlerden birine eklenebilir mi kontrol edilmelidir. Ayrıcalıkların içerisinde kullanıcının erişmemesi gereken bir form, tablo var mı detaylı olarak analiz edilmelidir. Eğer bir olumsuzluk tespit edilmediyse ve halihazırda sahip olduğu bir rolün altında yer alan göreve eklenmesi de uygunsa herhangi yeni bir nesne geliştirilmemeli mevcut ayrıcalık mevcut bir göreve ya da yeni bir göreve eklenmelidir.

Tespit edilen ayrıcalığın mevcut göreve atanmasında sakınca görülürse yeni bir görev tanımlanmalı ve mevcut ayrıcalık yeni göreve atanmalıdır.

Eğer ilgili nesneye erişebilen ayrıcalıkların kullanılmasında sakınca var ise yeni bir ayrıcalık geliştirilmeldir. Ancak bu noktada yeni bir ayrıcalık oluşturulmadan önce önceki adımlar iyice kontrol edilmelidir. Çünkü AX’ ta yer alan neredeyse her form ve fonksiyon için en az bir ayrıcalık standart pakette sunulmuştur. Birçok formda ise hem görme hem de silme için ayrı ayrı ayrıcalık tanımlanmıştır. Standart nesneler için bu kadar ayrıcalık tanımlanmışken ihtiyaç duyulan nesneye uygun bir ayrıcalık bulunamadıysa tekrar kontrol edilmelidir.

5. Yeni Yetki Nesneleri Oluşturmak

Yetki talep edilen nesneye mevcutta erişebilen rol, görev ya da ayrıcalık bulunamadıysa yeni bir ayrıcalık oluşturulmalıdır. Bu noktada standart ayrıcalıklar referans alınarak best practicelere uygun hareket edilmelidir. Ayrıcalık oluştururken kişi bazlı düşünüp o kişinin ihtiyaç duyduğu tüm nesneleri tek bir ayrıcalığa vermek doğru değildir. Ayrıcalık oluştururken ekran, form ya da fonksiyon bazlı düşünülmelidir. Mümkün mertebe her form, ekran, rapor, fonksiyon için en az bir ayrıcalık oluşturulmalıdır. Görüntüleme ve tam kontrolün ayrılabileceği yerlerde iki ayrı ayrıcalık oluşturulmalıdır. Bu sayede custom nesnelere yetki verilmek istendiğinde her seferinde yeniden geliştirme yapılmasına gerek kalmayacaktır. Custom nesne için yapılan ayrıcalık ve görevler tekrar tekrar kullanılabilecektir. Ayrıcalık, görev ve rol oluşturulurken de her birinin ayrı ayrı anlamlı ve kullanılabilir olmasına dikkat edilmelidir.

Reklamlar
Sistem Kullanıcısı Rolü Yetki Problemi

Sistem Kullanıcısı Rolü Yetki Problemi

Dynamics AX projelerinde kullanıcıların bazı temel işlevleri yerine getirebilmeleri için tüm kullanıcılara Sistem kullanıcısı ve Şirketiçi çalışan rollerinin verilmesi tavsiye edilir. Bu sayede yetki çalışmalarında kolaylık sağlanmış olur. Ancak projemizde karşılaşmış olduğumuz bir sorun bu yetkilerin de canlıya geçmeden önce tekrar kontrol edilmesi gerektiğini ortaya çıkardı.

Projemizde yetkilendirme çalışması yaparken bir genel muhasebe rolüne Finansal boyutlar ve Boyut değerleri formlarına sadece okuma yetkisi vermemize rağmen ilgili role atanan kullanıcının silme yetkisine sahip olduğunu gördük. Detaylı olarak analiz ettik, tüm menü itemları, tablo yetkilerini inceledik. Tüm yetkiler doğru tanımlanmış gözüküyordu. Daha sonra kullanıcıdan Sistem kullanıcısı ve Şirketiçi çalışan yetkilerini kaldırarak denediğimizde boyut formlarında sadece okuma yetkisiyle yani istediğimiz şekilde çalıştığını gördük. İki rolü detaylı inceleyince sorunun Sistem kullanıcısının altında yer alan DimensionEssentials privilege inden kaynaklandığını gördük. DimensionEssentials privilege ini AOT den açıp Permission > Tables nodunun altına bakılırsa birçok tabloya yetki verildiği görülüyor.

sis-1

Bunların birçoğu Read yetkisinde ama aralarında finansal boyutlar ve hesap tablosu gibi bazı önemli tablolarda Create ya da Delete yetkisi verilmiş.

sis-2

Finansal boyut tablolarınının sadece görecek şekilde kısıtlanması için aşağıdaki tablolarda erişim seviyesininin Create den Read e getirilmesi gerekiyor:

  • DimensionAlias
  • DimensionAttribute
  • DimensionAttributeLevelValue
  • DimensionAttributeSet
  • DimensionAttributeSetItem
  • DimensionAttributeValue
  • DimensionAttributeValueCombination
  • DimensionAttributeValueCombinationStatus
  • DimensionAttributeValueConsolidation
  • DimensionAttributeValueCostAccounting
  • DimensionAttributeValueFinancialStmt
  • DimensionAttributeValueGroup
  • DimensionAttributeValueGroupCombination
  • DimensionAttributeValueGroupStatus
  • DimensionAttributeValueSet
  • DimensionAttributeValueSetItem
  • DimensionAttributeValueTotallingCriteria
  • DimensionFinancialTag
  • DimensionAttributeValueConsolidation

Aslında sadece DimensionAttributeValue ve DimensionFinancialTag tablolarını kısıtlayınca sorun çözülüyor. Tedbir amaçlı diğer tabloları da read seviyesine çektim. İhtiyaç duyulursa değiştirilebilir. Ancak bu tabloların yetkilerinin Sistem kullanıcısı yerine spesifik bir rol üzerinden verilmesi gerektiğini düşünüyorum.

Hesap tablolarınının sadece görecek şekilde kısıtlanması için aşağıdaki tablolarda erişim seviyesininin Create den Read e getirilmesi gerekiyor:

  • MainAccount
  • MainAccountControlPosting

Bunların haricinde diğer tablolar da kontrol edilip ihtiyaca göre erişim seviyesi düzenlenebilir.

Yetkilendirmede Adım-6: Rollere Kullanıcı Atama

Yetkilendirmede Adım-6: Rollere Kullanıcı Atama

Rollerin de tanımlanmasından sonra kullanıcılara rol atanmasıyla yetkilendirme işlemi tamamlanmış olur. Sistemdeki kullanıcıları rol atamak için birkaç yol vardır. Role kullanıcı veya kullanıcıya rol ataması yapılabilir. Ayı zamanda herhangi bir kişi birden fazla role de atanabilir.

Okumaya devam et “Yetkilendirmede Adım-6: Rollere Kullanıcı Atama”

Yetkilendirmede Adım-3: Güvenlik Ayrıcalıkları

Yetki tanımlamada görevlerin tanımlanmasından sonra güvenlik ayrıcalıkları tanımlanır. Güvenlik ayrıcalıkları görevlerin gerçekleştirebileceği işleri ifade eder.  Sistemde mevcut görevler için birçok ayrıcalık tanımlı olarak bulunmaktadır. Tanımlı ayrıcalıkları görmek ya da düzenlemek için Sistem yönetimi > Kurulum > Güvenlik > Güvenlik ayrıcalıkları yolunu kullanıp güvenlik ayrıcalıkları formunu açtıktan sonra ağaç yapısında incelemek istediğimiz ayrıcalık hangi süreç döngüsünün ve görevin altında yer alıyorsa o süreç döngüsünü ve görevi genişleterek kapsadığı ayrıcalıkları görebiliriz.

Okumaya devam et “Yetkilendirmede Adım-3: Güvenlik Ayrıcalıkları”

Yetkilendirmede Adım-2: Görevler

 

Yetki tanımlamada süreç döngüsünün tanımlanmasından sonra görevler tanımlanmalıdır. Sistemde mevcut süreç döngüleri için birçok görev tanımlı olarak bulunmaktadır. Tanımlı görevleri görmek ya da düzenlemek için Sistem yönetimi > Kurulum > Güvenlik > Güvenlik ayrıcalıkları yolunu kullanıp güvenlik ayrıcalıkları formunu açtıktan sonra ağaç yapısında incelemek istediğimiz görev hangi süreç döngüsünün altında yer alıyorsa o süreç döngüsünü genişleterek kapsadığı görevleri görebiliriz.

Okumaya devam et “Yetkilendirmede Adım-2: Görevler”

Yetkilendirmede Adim-1 Süreç Döngüleri

Yetkilendirmede Adim-1 Süreç Döngüleri

Rol tabanlı güvenlik yapısında yetki tanımlama hiyerarşik bir yapıdadır. Hiyerarşide en üstte yer alan adım süreç döngüleridir.

Yetki tanımlama işleminde ilk adım süreç döngüsünün tanımlanmasıdır. Ya da standart modüller üzerinden yetkilendirme yapacaksak tanımlayacağımız bir görev sistemde bulunan süreç döngülerinden birinin altında olmalıdır.

Okumaya devam et “Yetkilendirmede Adim-1 Süreç Döngüleri”