11 Kas 2025·8 dk
İç Araç İzinlerini Yönetmek İçin Bir Web Uygulaması Nasıl Kurulur?
Roller, onaylar, denetim günlükleri ve güvenli işlemler içeren bir iç araç erişim yönetimi web uygulamasını tasarlama ve inşa etme adım adım rehberi.
Roller, onaylar, denetim günlükleri ve güvenli işlemler içeren bir iç araç erişim yönetimi web uygulamasını tasarlama ve inşa etme adım adım rehberi.
RBAC rollerini ve izinleri seçmeden veya ekranları tasarlamaya başlamadan önce, kuruluşunuzda “iç araç izinleri”nin ne anlama geldiğini netleştirin. Bazı ekipler için bu basitçe “kim hangi uygulamaya erişebiliyor” iken, bazılarında her araç içindeki ayrıntılı eylemler, geçici yetki yükseltmeleri ve denetim delilleri de dahildir.
Kontrol etmeniz gereken kesin eylemleri, insanların çalışma biçimine uyan fiiller kullanarak yazın:
Bu liste, erişim yönetimi web uygulamanız için temel olmalıdır: ne depolayacağınızı, neyi onaylayacağınızı ve neyi denetleyeceğinizi belirler.
İç sistemlerin ve araçların bir envanterini çıkarın: SaaS uygulamaları, dahili yönetici panelleri, veri ambarları, paylaşılan klasörler, CI/CD ve varsa “gölge admin” tabloları. Her biri için izinlerin nerede uygulandığını not edin:
Uygulama “süreç ile” ise, bunu kaldırmalı veya açıkça kabul etmelisiniz; aksi halde bir risk taşır.
Karar vericileri ve operasyon ekibini belirleyin: BT, güvenlik/uyumluluk, takım liderleri ve erişim isteyen son kullanıcılar. Ölçülebilir başarı metriklerinde anlaşın:
Doğru kapsamı belirlemek, çalıştırması çok karmaşık veya asgari ayrıcalığı koruyamayacak kadar basit bir izin sistemi inşa etmenizi engeller.
Yetkilendirme modeliniz, izin sisteminizin “şeklidir”. Bunu erken doğru yapın; UI, onaylar, denetimler ve uygulama basitleşir.
Çoğu iç araç, role dayalı erişim kontrolü (RBAC) ile başlayabilir:
RBAC açıklaması ve gözden geçirilmesi en kolay olandır. Sık sık “özel durum” istekleri görüyorsanız geçersiz kılmaları ekleyin. Rollerinizin sayısını patlatacak tutarlı kurallar olduğunda ABAC'a geçin (ör. “araç X'e sadece kendi bölgesi için erişebilir”).
Rolleri öyle tasarlayın ki varsayılan erişim en düşük olsun ve ayrıcalık açık atamayla kazanılsın:
İzinleri iki düzeyde tanımlayın:
Bu, bir aracın gereksinimlerinin diğer her aracı aynı rol yapısına zorlamasını engeller.
İstisnalar kaçınılmazdır; onları açık hale getirin:
İstisnalar sıklaşırsa, rollerinizi ayarlamanız veya politika kuralları eklemeniz gerektiğini gösterir—tek seferliklerin kalıcı ve gözden geçirilmemiş ayrıcalığa dönüşmesine izin vermeyin.
Bir izin uygulaması veri modeline bağlıdır. "Kimin neye erişimi var ve neden?" sorusuna hızlı ve tutarlı yanıt veremiyorsanız, diğer özelliklerin hepsi (onaylar, denetimler, UI) kırılgan olur.
Gerçek dünya kavramlarına temizce eşlenen küçük bir tablo/kolleksiyon seti ile başlayın:
export_invoices gibi ince taneli yetenekler)Roller çoğunlukla bir araç içinde anlamlıdır; genelde bir rol sadece bir araç bağlamında anlam ifade eder (ör. Jira'da "Admin" ile AWS'de "Admin" farklıdır).
Çoktan-çoğa ilişkiler bekleyin:
Takım tabanlı miras destekliyorsanız kuralı baştan belirleyin: etkili erişim = doğrudan kullanıcı atamaları artı takım atamaları; çakışmalarda net bir çözüm olmalı (ör. "deny, allow'dan üstün" gibi).
Zaman içindeki değişiklikleri açıklayan alanlar ekleyin:
created_by (kimin verdiği)expires_at (geçici erişimler)disabled_at (geçmişi kaybetmeden yumuşak devre dışı bırakma)Bunlar, "bu erişim geçen Salı geçerli miydi?" sorusunu cevaplamada kritik öneme sahiptir.
En sık sorgunuz genelde: "Kullanıcı X, araç Z'de izin Y'ye sahip mi?" olacaktır. Atamaları (user_id, tool_id) ile indeksleyin ve kontrollerin anında olması gerekiyorsa “etkili izinleri” önceden hesaplayın. Yazma yollarını basit tutun, ancak uygulama buna bağımlıysa okuma yollarını optimize edin.
Kimlik doğrulama, kişilerin kim olduğunu kanıtlamasıdır. İç izin uygulaması için amaç çalışanların girişini kolaylaştırmak ve yönetici işlemlerini güçlü şekilde korumaktır.
Genelde üç seçeneğiniz vardır:
Birden fazla yöntem destekliyorsanız, birini varsayılan yapın ve diğerlerini açık istisnalar olarak belirtin—aksi halde yöneticiler hesapların nasıl oluşturulduğunu tahmin etmekte zorlanır.
Modern entegrasyonların çoğu OIDC kullanır; bazı işletmeler hala SAML ister.
Protokolden bağımsız olarak IdP'den neyi güvendiğinizi belirleyin:
Oturum kurallarını önceden tanımlayın:
IdP girişte MFA uyguluyor olsa bile, yönetici hakları verme, onay kurallarını değiştirme veya audit loglarını dışa aktarma gibi yüksek etkili işlemler için adım yükseltme kimlik doğrulaması ekleyin. Pratikte bu, işlemi tamamlamadan önce "MFA kısa süre önce yapıldı mı"yı kontrol etmek veya yeniden kimlik doğrulaması zorunlu kılmak anlamına gelir.
Bir izin uygulamasının başarısı tek bir şeye bağlıdır: insanların ihtiyaç duydukları erişimi risk oluşturmadan elde edebilmesi. Açık bir istek ve onay akışı erişimi tutarlı, incelenebilir ve sonradan denetlenebilir kılar.
Basit, tekrarlanabilir bir yolla başlayın:
İstekleri yapılandırılmış tutun: serbest metin "lütfen bana admin ver" yerine, önceden tanımlı bir rol veya izin paketi seçimini zorunlu kılın ve kısa bir gerekçe isteyin.
Onay kurallarını baştan tanımlayın ki onaylar tartışmaya dönüşmesin:
Standart erişim için "yönetici + uygulama sahibi" gibi bir politika kullanın; ayrıcalıklı roller için güvenliği zorunlu kılın.
Varsayılan olarak zaman-sınırlı erişim (ör. 7–30 gün) tercih edin ve sadece kısa bir stabil rol listesini "kaldırılana kadar" erişime izin verin. Verme iş akışı aynı zamanda kaldırma zamanını planlamalı ve sona ermeden önce kullanıcıyı bildirmelidir.
Olay müdahalesi için bir “acil” yol destekleyin, ancak şu güvenceleri ekleyin:
Böylece hızlı erişim görünmez erişim anlamına gelmez.
Yönetici panonuz, “tek tıkla” bordro verilerine erişim izni verme veya prod haklarını iptal etme gücüne sahiptir. İyi bir UX her izin değişikliğini yüksek riskli bir düzenleme olarak ele alır: açık, geri alınabilir ve kolayca incelenebilir.
Yöneticilerin düşündüğü şekilde bir gezinme yapısı kullanın:
Bu düzen "nereye gideyim?" hatalarını azaltır ve yanlış yerde yanlış şeyi değiştirmeyi zorlaştırır.
İzin isimleri önce sade dilde, sonra teknik detayla gösterilmelidir. Örnek:
Rolün etkisini kısa bir özetle gösterin ("12 kaynağa erişim veriyor, Prod dahil") ve tam dökümü ilişkilendirin.
Sürtünmeyi kasıtlı kullanın:
Yöneticiler hız ister ama güvenlikten vazgeçmek istemez. Kullanımda arama, filtreler (uygulama, rol, departman, durum) ve sayfalama sağlayın. Filtre durumunu URL'de tutun ki sayfalar paylaşılabilir ve tekrar üretilebilir olsun.
Uygulama katmanı, izin modelinizin gerçeğe dönüştüğü yerdir. Sıkıcı, tutarlı ve atlatılması zor olmalıdır.
Tek bir fonksiyon (veya küçük bir modül) oluşturun: "Kullanıcı X, kaynak Z üzerinde Y eylemini yapabilir mi?" Her UI kontrolü, API handler, arkaplan işi ve yönetici aracı bunu çağırmalı.
Bu, zaman içinde farklılaşan "yaklaşık yeterli" yeniden uygulamaların önüne geçer. Girdileri açık tutun (kullanıcı id, eylem, kaynak türü/id, bağlam) ve çıktıları katı yapın (allow/deny ve denetim için bir neden).
Düğmeleri gizlemek güvenlik değildir. Sunucuda şu yerlere izin kontrolü koyun:
İyi bir desen, konuyu (resource) yükleyen, izin-denetim fonksiyonunu çağıran ve karar "deny" ise kapatan (403) bir middleware kullanmaktır. UI /api/reports/export çağrıyorsa, export endpoint'i UI düğmesini devre dışı bırakmış olsa bile aynı kuralı uygulamalıdır.
İzin kararlarını önbelleğe almak performansı artırabilir, ancak rol değişikliğinden sonra erişimin devam etmesine de neden olabilir.
Rol tanımları ve politika kuralları gibi yavaş değişen girdileri önbelleğe almayı tercih edin; karar önbelleklerini kısa ömürlü tutun. Rol güncellemeleri, kullanıcı rol atama değişiklikleri veya deprovision gibi olaylarda önbellekleri temizleyin. Eğer kullanıcı bazlı kararları önbelleklemeniz gerekirse, kullanıcı için bir "permissions version" sayacı ekleyin ve herhangi bir değişiklikte onu artırın.
Kaçının:
Somut bir referans uygulama deseni istiyorsanız, bunu mühendislik çalıştırma kitabınıza (ör. /docs/authorization) dökümante edin ve yeni endpointlerin aynı uygulama yolunu izlemesini sağlayın.
Audit günlükleri, izinler için "fiş sistemi"nizdir. Birisi "Alex'in Bordroya neden erişimi var?" diye sorduğunda dakikalar içinde cevap verebilmelisiniz—chat geçmişinde ya da tahmin ederek kazara değil.
Her izin değişikliği için kimin, neyi, ne zaman ve neden kaydedin. "Neden" sadece serbest metin olmamalı; değişikliğe gerekçe olan iş akışıyla ilişkilendirilmelidir.
En azından şunları yakalayın:
Finance-Read → Finance-Admin)Tutarlı bir olay şeması kullanın ki raporlama güvenilir olsun. UI değişse bile audit hikayesi okunabilir kalır.
Her veri okuması loglanmaz ama yüksek riskli verilere erişimler genelde loglanmalıdır. Örnekler: bordro detayları, müşteri PII exportları, API anahtarı görüntülemeleri veya "tümünü indir" eylemleri.
Okuma-logging'i pratik tutun:
Yöneticilerin gerçekten kullandığı temel raporları sağlayın: "kişiye göre izinler", "X'e kim erişebilir" ve "son 30 gündeki değişiklikler". Denetçiler için export seçenekleri (CSV/JSON) ekleyin fakat exportları hassas işlem olarak ele alın:
Saklama süresini baştan belirleyin (ör. düzenlemeye bağlı 1–7 yıl) ve görevleri ayırın:
Eğer yönetici UI'nizde özel bir "Audit" alanı ekliyorsanız, /admin’den buna bir bağlantı verin; açık uyarılar ve arama-öncelikli bir tasarım sunun.
İzinsel sürüklenme, insanların katılması, takım değiştirmesi, izne ayrılması veya ayrılması sırasında olur. Sağlam bir erişim yönetimi uygulaması kullanıcı yaşam döngüsünü birincil özellik olarak ele almalıdır.
Kimlik için net bir doğruluk kaynağı belirleyin: İK sistemi, IdP (Okta, Azure AD, Google) veya her ikisi. Uygulamanızın şunları yapabilmesi gerekir:
IdP SCIM destekliyorsa kullanın. SCIM, kullanıcıları, grupları ve durum değişikliklerini otomatik senkronize eder; manuel işi azaltır ve "hayalet kullanıcı"ları önler. SCIM yoksa periyodik importlar planlayın (API veya CSV) ve istisnaları sahiplerinden incelemelerini isteyin.
Takım taşınmaları izinlerin en çok karıştığı durumlardır. "Takım"ı yönetilen bir özellik olarak modelleyin (HR/IdP'den senkronize edilen) ve mümkünse rol atamalarını türetilmiş kurallar olarak ele alın (ör. "department = Finance ise Finance Analyst rolü ver").
Birisi takım değiştirdiğinde uygulamanız şunları yapmalı:
Offboarding erişimi hızlı ve öngörülebilir şekilde iptal etmelidir. IdP'den (kullanıcıyı devre dışı bırakma) tetiklenen kapanış sonrası uygulamanız hemen:
Uygulamanız aynı zamanda aşağı araçlara erişim sağlayan bir sistemse, bu kaldırmaları kuyruğa alın ve yönetici panosunda herhangi bir başarısızlığı gösterin ki hiçbir şey fark edilmeden kalmasın.
Bir izin uygulaması cazip bir hedeftir çünkü birçok iç sistem için erişim verebilir. Güvenlik tek bir özellik değil—saldırganın (veya aceleci bir yöneticinin) zarar vermesini azaltan küçük, tutarlı kontrollerin bir setidir.
Her form alanını, sorgu parametresini ve API yükünü güvensiz kabul edin.
Ayrıca UI'de güvenli varsayılanlar koyun: "erişim yok" ön seçili olsun ve yüksek etkili değişiklikler için açık onay gerektirin.
UI hataları azaltmalı ama güvenlik sınırı olmamalıdır. Hassas endpointler şu kontrollerle gelmelidir:
Bu, bir mühendislik kuralı olarak ele alınmalı: hiçbir hassas endpoint yetkilendirme kontrolü ve bir audit olayı olmadan üretime çıkmamalıdır.
Yönetici endpointleri ve kimlik doğrulama akışları kaba kuvvet ve otomasyon hedefidir.
Mümkünse, riskli eylemler için adım yükseltme doğrulaması isteyin (yeniden kimlik doğrulama veya ek onay gibi).
SSO istemci gizli anahtarları, API tokenları gibi sırları kaynak kodunda veya yapılandırma dosyalarında değil, özel bir sır yöneticisinde saklayın.
Düzenli olarak test edin:
Bu kontroller ucuzdur ve izin sistemlerinin en yaygın hatalarını yakalar.
İzin hataları genelde "uygulama bozuk" değil, "yanlış kişi yanlış şeyi yapabiliyor" hatalarıdır. Yetkilendirme kurallarını iş mantığı olarak ele alın; girdi ve beklenen çıktıları net olan senaryolar yazın.
İzin değerlendiricinizi (allow/deny kararını veren fonksiyon) birim testleriyle başlayarak test edin. Testleri senaryo isimlendirmesiyle okunur tutun.
İyi bir desen, küçük bir vaka tablosu (kullanıcı durumu, rol, kaynak, eylem → beklenen karar) tutmaktır.
Birim testleri kablo bağlantısı hatalarını yakalamaz—ör. controller'ın izin denetimini unutması. En çok önem taşıyan akışlar için entegrasyon testleri ekleyin:
Bu testler UI'nin kullandığı aynı endpointlere isabet ederek API cevaplarını ve veritabanı değişikliklerini doğrulamalıdır.
Roller, takımlar, araçlar ve örnek kullanıcılar (çalışan, yüklenici, admin) için kararlı fixture'lar oluşturun. Bunları sürümlü ve tüm testlerin paylaşacağı şekilde tutun ki herkes aynı "Finance Admin" veya "Support Read-Only" anlamıyla test etsin.
İzin değişiklikleri için hafif bir kontrol listesi ekleyin: yeni roller, varsayılan rol değişimleri, atamaları etkileyen migrationlar ve yönetici ekranlarındaki UI değişiklikleri. Mümkünse bu kontrol listesini sürüm sürecine bağlayın.
Bir izin sistemi asla "kur ve unut" değildir. Gerçek sınav lansmandan sonra başlar: yeni takımlar katılır, araçlar değişir ve acil erişim ihtiyaçları en kötü zamanda gelir. Operasyonları ürünün bir parçası olarak ele alın.
dev, staging ve productionu izole tutun—özellikle verilerini. Staging, üretim konfigürasyonunu (SSO ayarları, politika anahtarları, feature flagler) yansıtmalı, ancak ayrı kimlik grupları ve duyarlı olmayan test hesapları kullanmalıdır.
Ayrıca ayırın:
Uptime ve gecikme gibi temel metriklerin yanına izin-özel sinyaller ekleyin:
Uyarıları eyleme geçirilebilir yapın: kullanıcı, araç, değerlendirilen rol/politika, istek ID'si ve ilgili audit olayına link içermeli.
Yaygın acil durumlar için kısa runbook'lar yazın:
Runbook'ları repoda ve operasyon wikinizde tutun; tatbikatlarda test edin.
Yeni bir iç uygulama olarak uyguluyorsanız, en büyük risk aylarca altyapı üzerine çalışıp (auth akışları, yönetici UI, audit tabloları, istek ekranları) gerçek takımlarla modeli doğrulamadan ilerlemektir. Pratik yaklaşım; minimal bir sürüm hızlıca yayınlayıp ardından politika, logging ve otomasyon ile güçlendirmektir.
Ekiplerin yaptığı bir yol, başlangıç admin panosunu, istek/onay akışlarını ve CRUD veri modelini hızlı üretmek için Koder.ai gibi sohbet bazlı kod üretim platformlarını kullanmaktır. Bu tür araçlar genelde React web, Go + PostgreSQL backend gibi standart mimarilere dayalı kaynak kodunu dışa aktarmaya izin verirken, planlama modu, snapshot/geri alma gibi özelliklerle yetkilendirme kurallarını güvenle yinelemenize yardımcı olabilir.
Roller tasarımına daha sağlam bir temel atmak istiyorsanız blog/role-based-access-control-basics içeriğine bakın. Paketleme ve dağıtım seçenekleri için pricing sayfasına bakabilirsiniz.
Bir izin, kontrol etmek istediğiniz belirli bir eylemdir; insanların çalışma biçimine uyan bir fiille ifade edilir — örneğin view, edit, admin veya export.
Başlamak için pratik bir yol, her araç ve ortam (prod vs staging) için eylemleri listelemek ve adları standardize ederek incelenebilir ve denetlenebilir hale getirmektir.
Erişimin önemli olduğu her sistemi envantere alın — SaaS uygulamaları, dahili yönetici panelleri, veri ambarları, CI/CD, paylaşılan klasörler ve varsa “gölge yönetici” tabloları.
Her araç için kaydedin: izinler nerede uygulanıyor:
Süreç bazlı uygulama varsa, bunun açıkça bir risk olduğunu kabul edin veya kaldırmaya öncelik verin.
Hem hız hem güvenlik yansıtan ölçümleri takip edin:
Bunlar sistemin operasyonları iyileştirip riskleri azaltıp azaltmadığını gösterir.
Gerçek dünyadaki istisnalar göz önünde bulundurulmadan en basit modeli seçin:
İnceleme ve denetim sırasında anlaşılır kalan en basit yaklaşımı seçin.
Varsayılanı en az ayrıcalıklı olacak şekilde ayarlayın ve daha fazla erişim için açık atama isteyin:
En az ayrıcalık, açıklaması ve gözden geçirilmesi kolay olduğunda en iyi çalışır.
Global izinler organizasyon genelindeki yetenekler için (ör. kullanıcıları yönetme, audit günlüklerini görüntüleme, erişimi onaylama) tanımlanır; araç-spesifik izinler ise her aracın içindeki eylemler içindir (ör. prod'a deploy, sırları görüntüleme).
Bu ayrım, bir aracın karmaşıklığının diğer tüm araçları aynı rol yapısına zorlamasını önler.
En azından aşağıdaki modelleri oluşturun:
Ayrıca created_by, expires_at ve gibi yaşam döngüsü alanları ekleyin ki tarihsel soruları (ör. "Bu erişim geçen Salı geçerli miydi?") kesin olarak yanıtlayabilesiniz.
İç uygulamalar için SSO tercih edin:
IdP'den neyi güvenilir bulduğunuza karar verin: yalnızca kimlik mi, yoksa kimlik + gruplar mı (bazı durumlarda temel rolleri otomatik atamak için).
Yapılandırılmış bir akış kullanın: istek → karar → atama → bildirim → denetim.
İstekler önceden tanımlanmış roller/paketler seçtirilmeli (serbest metin yerine) ve kısa bir iş gerekçesi istenmelidir. Onay kurallarına örnek:
Varsayılan olarak zaman-sınırlı erişim tercih edin ve otomatik sona erdirme uygulayın.
Değişiklikleri eklenemez bir iz olarak kaydedin: kimin neyi, ne zaman ve neden değiştirdiği, eski → yeni değerler ve isteği/onayı destekleyen ID veya ticket ID'si dahil.
Ayrıca:
disabled_at