İç Araç İzinlerini Yönetmek İçin Bir Web Uygulaması Nasıl Kurulur?

Problemi ve kapsamı tanımlayın

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.

İzin olarak sayılan nedir?

Kontrol etmeniz gereken kesin eylemleri, insanların çalışma biçimine uyan fiiller kullanarak yazın:

• View (panolara, ticketlara, müşteri kayıtlarına salt okunur erişim)
• Edit (konfigürasyon değiştirme, veriyi güncelleme, istekleri kapatma)
• Admin (kullanıcıları yönetme, faturalamayı değiştirme, güvenlik ayarlarını değiştirme)
• Export (rapor indirme, müşteri verisi çekme, API erişimi)

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.

Araç envanteri ve uygulamanın nerede yapıldığı

İç 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:

• Araç içinde (yerel roller)
• Ağ geçidinizde (reverse proxy, API katmanı)
• Süreç ile (manuel adımlar, paylaşılan kimlik bilgileri)

Uygulama “süreç ile” ise, bunu kaldırmalı veya açıkça kabul etmelisiniz; aksi halde bir risk taşır.

Paydaşlar ve başarı metrikleri

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:

• Erişim verme için medyan süre
• İzinle ilgili olay sayısı
• Bir sahibi ve iş gerekçesi olan erişim yüzdesi
• Denetime hazırlık ("kimin neye, ne zaman ve neden erişimi vardı?" sorusunu cevaplayabiliyor musunuz?)

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 modelinizi seçin (roller, politikalar ve istisnalar)

Yetkilendirme modeliniz, izin sisteminizin “şeklidir”. Bunu erken doğru yapın; UI, onaylar, denetimler ve uygulama basitleşir.

Gerçeği kaldırabilecek en basit modelle başlayın

Çoğu iç araç, role dayalı erişim kontrolü (RBAC) ile başlayabilir:

• Basit roller: kullanıcılar bir veya daha fazla rol alır (ör. Viewer, Operator, Admin).
• Rol + geçersiz kılmalar: roller vakaların %90'ını kapsar, kalan için kullanıcı bazlı açık izin/verme/engelleme seti.
• Attribute-based kurallar (ABAC): izinler departman, lokasyon, veri hassasiyeti veya ortam gibi özniteliklere bağlıdır.

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”).

Asgari ayrıcalığı varsayılan yapın

Rolleri öyle tasarlayın ki varsayılan erişim en düşük olsun ve ayrıcalık açık atamayla kazanılsın:

• "Erişim yok" veya "yalnızca okuma" temelleriyle başlayın.
• "Görüntüle"yi "değiştir"den ayırın (ve "onaylayabilir" ile "isteyebilir"i ayırın).
• Tümünü gizlice içeren “Admin” rollerinden kaçının; yüksek etkili eylemleri görünür yapın.

Global ile araç-spesifik olanı ayırın

İzinleri iki düzeyde tanımlayın:

• Global izinler: organizasyon genelindeki yetenekler ("kullanıcıları yönet", "audit günlüklerini görüntüle", "erişimi onayla")
• Araç-spesifik izinler: her araç içindeki eylemler (ör. deploy, yapılandırma düzenleme, sırları görüntüleme)

Bu, bir aracın gereksinimlerinin diğer her aracı aynı rol yapısına zorlamasını engeller.

Modelinizi bozmadan istisnalar planlayın

İstisnalar kaçınılmazdır; onları açık hale getirin:

• Geçici erişim: otomatik olarak süresi dolan zaman sınırlı izinler.
• Break-glass admin: ekstra korumalarla acil durum rolü (sınırlı süre, zorunlu sebep, ekstra kayıt).

İ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.

Veri modelini tasarlayın

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.

Temel varlıklar (açık tutun)

Gerçek dünya kavramlarına temizce eşlenen küçük bir tablo/kolleksiyon seti ile başlayın:

• Users (erişim ihtiyacı olan kişiler)
• Teams (erişim için yönettiğiniz gruplar)
• Tools/Apps (erişimin verildiği nesneler)
• Roles ("Billing Admin" gibi adlandırılmış paketler)
• Permissions (export_invoices gibi ince taneli yetenekler)
• Assignments (bir kullanıcı/takımın belli bir araç için rolü aldığı kayıt)

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).

İlişkiler ve miras kuralları

Çoktan-çoğa ilişkiler bekleyin:

• Bir kullanıcı, birçok takıma ait olabilir; bir takım çok sayıda kullanıcı içerir.
• Bir rol, birçok izne sahip olabilir; bir izin birçok rolde olabilir.
• Bir atanma tipik olarak şunu bağlar: (konu = kullanıcı veya takım) → (rol) → (araç/uygulama).

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).

Denetimleri kolaylaştıran yaşam döngüsü alanları

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.

Hızlı izin kontrolleri için indeksleme

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 ve SSO entegrasyonu

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.

Giriş yöntemini seçin

Genelde üç seçeneğiniz vardır:

• SSO (çoğu şirket için önerilir): çalışanlar kurumsal kimlikleriyle (Google Workspace, Microsoft Entra ID/ADFS, Okta, Ping) giriş yapar.
• E-posta magic link (parolasız): kullanıcı e-postasını girer ve zaman sınırlı bir bağlantı alır. Yönetimi basittir, ancak posta kutusu güvenliği değişkense zayıftır.
• Parolalar: genelde iç araçlar için son tercih; parola sıfırlama ve politika yükü oluşturur.

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.

SAML veya OIDC ile entegrasyon

Modern entegrasyonların çoğu OIDC kullanır; bazı işletmeler hala SAML ister.

• OIDC: bir ID token doğrulaması yaparsınız, stabil bir kullanıcı tanımlayıcısını (subject/issuer) eşlersiniz ve isteğe bağlı olarak grup/rol claim'lerini okursunuz.
• SAML: imzalı assertion'ları doğrular, NameID (veya özel bir attribute) eşlersiniz ve metadata/sertifika döndürme işlemlerini yönetirsiniz.

Protokolden bağımsız olarak IdP'den neyi güvendiğinizi belirleyin:

• Yalnızca kimlik (kullanıcının kim olduğu), uygulamanız izinleri saklar.
• Kimlik + gruplar (kullanıcının kim olduğu ve hangi gruplarda olduğu), bu temel rollerin otomatik atanmasına izin verebilir.

Oturumlar: süre, yenileme ve cihaz güveni

Oturum kurallarını önceden tanımlayın:

• Kısa ömürlü erişim oturumu (ör. 8–12 saat) ve yeniden kimlik doğrulama istemi.
• Yenileme stratejisi: ya IdP üzerinden sessiz yenileme (OIDC) ya da süre bitiminde yeniden giriş (daha basit, daha güvenli).
• Cihaz güveni: düşük riskli işlemler için cihazı hatırlama seçeneği, ancak yönetici değişiklikleri için yeniden doğrulama gerektirin. Oturumları cihaz başına izleyin ki yöneticiler bunları iptal edebilsin.

Hassas yönetici işlemleri için MFA

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.

Erişim isteği ve onay iş akışları

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.

Temel akış: istek → karar → ver

Basit, tekrarlanabilir bir yolla başlayın:

1. Kullanıcı erişim isteği yapar (belirli araç, ortam ve izin seti için).
2. Onaycılar isteği inceler (iş gerekçesi ve süre gibi bağlamla birlikte).
3. Sistem onaydan sonra otomatik atama yapar (veya otomasyon yoksa yönetici görevleri oluşturur).
4. Kullanıcı bilgilendirilir ve atama audit kaydına geçirilir.

İ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.

Kimi neyin onaylayabileceğini belirleyin

Onay kurallarını baştan tanımlayın ki onaylar tartışmaya dönüşmesin:

• Yönetici onayı isteğin kullanıcının iş sorumluluklarına uyduğunu doğrular.
• Uygulama sahibi onayı izin seviyesinin araç için uygun olduğunu doğrular (ve genelde ortam için de).
• Güvenlik onayı yüksek etkili erişimler (admin roller, prod yazma, hassas veri) için ayrılmıştır.

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.

Zaman-sınırlı erişim ve otomatik sona erme

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.

Kontrolü kaybetmeden acil erişim

Olay müdahalesi için bir “acil” yol destekleyin, ancak şu güvenceleri ekleyin:

• Bir sebep kodu zorunlu (olay ticketı, kesinti referansı)
• Daha kısa varsayılan süre (saat bazında, gün değil)
• Uygulama sahiplerine ve güvenliğe ek logging ve uyarılar

Böylece hızlı erişim görünmez erişim anlamına gelmez.

Yönetici panosu UX'i hatalardan korur

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önetici dostu bir düzenle başlayın

Yöneticilerin düşündüğü şekilde bir gezinme yapısı kullanın:

• Users: kimin erişimi var ve neden
• Roles: yeniden kullanılabilir izin paketleri
• Apps/Resources: erişilebilecek nesneler
• Requests: bekleyen onaylar ve geçmiş
• Audit: kimin neyi ne zaman değiştirdiği

Bu düzen "nereye gideyim?" hatalarını azaltır ve yanlış yerde yanlış şeyi değiştirmeyi zorlaştırır.

İzinleri okunabilir yapın (sadece teknik doğru değil)

İzin isimleri önce sade dilde, sonra teknik detayla gösterilmelidir. Örnek:

• “View invoices” (scope: Billing → Invoices:read)
• “Deploy to production” (scope: CI/CD → prod:deploy)

Rolün etkisini kısa bir özetle gösterin ("12 kaynağa erişim veriyor, Prod dahil") ve tam dökümü ilişkilendirin.

Riskli eylemler için korunmalar ekleyin

Sürtünmeyi kasıtlı kullanın:

• Uygulamadan önce önizleme: "Bu 3 izin ekleyecek ve 1 izin kaldıracak."
• Hassas kapsamlar için onay kutuları ve doğrulamalar (prod, finans, İK)
• Toplu değişiklikler: CSV önizlemesi, geçersiz satırları vurgulama ve "anlıyorum" onay kutusu
• Kolay geri alma: değişiklik detay sayfasından "Bu değişikliği geri al" seçeneği

Büyük organizasyonlar için hız ve güvenlik

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ı: izinler nasıl gerçekten kontrol edilir

Uygulama katmanı, izin modelinizin gerçeğe dönüştüğü yerdir. Sıkıcı, tutarlı ve atlatılması zor olmalıdır.

Her yerde tek bir izin-denetim fonksiyonu

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).

Yolları ve API'leri koruyun (sadece UI değil)

Düğmeleri gizlemek güvenlik değildir. Sunucuda şu yerlere izin kontrolü koyun:

• Her API endpoint (dahili/yönetici endpointleri dahil)
• Sunucu tarafından renderlanan her rota
• Arkaplan görevleri (exportlar, senkronizasyonlar, zamanlanmış işler)

İ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.

Kararların güncel kalması için önbellekleme dikkatli kullanın

İ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ılması gereken yaygın tuzaklar

Kaçının:

• Gizli admin: "isEmployee=true" veya "workspace oluşturan" gibi koşulların her şeyi sessizce vermesi
• Unutulmuş endpointler: eski v1 rotaları, CSV exportlar, webhooklar, GraphQL alanları, dahili araçlar
• "Deny" boşlukları: eksik politika = izin. Varsayılan davranış açık olmak yerine reddet olmalıdır

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 ve raporlama

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.

Ne loglanmalı (ve kullanışlı yapmak için nasıl)

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:

• Aktör (admin/servis), hedef kullanıcı veya grup ve kaynak (araç, ortam, dataset)
• Eski değer → yeni değer (ör. Finance-Read → Finance-Admin)
• Zaman damgası (UTC) ve kaynak (UI, API, otomatik iş)
• Request ID ve approval ID (veya ticket ID) ki tam karar zincirini oynatabilesiniz
• Opsiyonel: iş gerekçesi, son kullanma tarihi ve izin veren politika

Tutarlı bir olay şeması kullanın ki raporlama güvenilir olsun. UI değişse bile audit hikayesi okunabilir kalır.

Hassas veri okuma işlemlerini loglama

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:

• Olayları loglayın, tüm yükü değil (günlüklerde hassas değerleri saklamaktan kaçının)
• Kaynak tanımlayıcıları, kullanılan filtreler ve ilgili hacmi yakalayın (örn. "2.431 satır dışa aktarıldı")
• Uyumluluk izin veriyorsa örneklemeyi belgeleyin

Raporlar ve exportlar (korumalarla)

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:

• Audit verilerini dışa aktarma için açık izin gerektirin
• Export dosyalarına kim ve ne zaman ürettiğini filigranlayın
• Export olayını (filtreler ve dosya formatı dahil) loglayın

Saklama ve audit izlerini kim görebilir

Saklama süresini baştan belirleyin (ör. düzenlemeye bağlı 1–7 yıl) ve görevleri ayırın:

• Sadece sınırlı roller audit günlüklerini görüntüleyebilir
• Salt okunur denetçi erişimi destekleyin
• Logları eklenemez ve müdahale tespit edilebilir yapın (ör. değiştirilemez depolama veya imzalı olay zincirleri)

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.

Kullanıcı yaşam döngüsü ve sağlama

İ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.

Sağlama: yeni kullanıcılar doğru erişimi nasıl alı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'de bir çalışan göründüğünde otomatik olarak kullanıcı kaydı oluşturmak.
• Asgari ayrıcalık kullanarak temel erişim atamak (ör. varsayılan "Employee" rolü + takım-spesifik roller).

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.

Rol değişiklikleri: takım taşınmalarını kaosa dönüştürmeden ele alma

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ı:

• Eski takım tabanlı rolleri otomatik kaldırma
• Açıkça onaylanmış istisnaları koruma (ve yeniden onaya işaret etme)

Kapatma: tüm araçlarda hızlı offboarding

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:

• Aktif oturumları ve API tokenlarını iptal etmelidir.
• Araç erişim atamalarını kaldırmalı ve araç sahiplerini bilgilendirmelidir.

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.

Güvenlik kontrolleri ve tehdit kontrolleri

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.

Girişleri doğrulayın ve yaygın web saldırılarını engelleyin

Her form alanını, sorgu parametresini ve API yükünü güvensiz kabul edin.

• Tür ve izin verilen değerleri doğrulayın (örn. rol isimleri sabit bir listeden, serbest metin değil).
• Daha sonra gösterilebilecek kullanıcı tarafından sağlanan metinleri sanitize edin (XSS önlemek için).
• Çerez tabanlı oturumlar için CSRF koruması kullanın, özellikle "ver/geri al" eylemlerinde.

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.

Sunucuda yetkilendirmeyi her zaman zorla

UI hataları azaltmalı ama güvenlik sınırı olmamalıdır. Hassas endpointler şu kontrollerle gelmelidir:

• Roller ve politikalar oluşturma/değiştirme
• Erişim verme, iptal etme veya istisnalar değiştirme
• Audit günlüklerini ve raporları görüntüleme

Bu, bir mühendislik kuralı olarak ele alınmalı: hiçbir hassas endpoint yetkilendirme kontrolü ve bir audit olayı olmadan üretime çıkmamalıdır.

Oran sınırlamaları ve kötüye kullanım kontrolleri

Yönetici endpointleri ve kimlik doğrulama akışları kaba kuvvet ve otomasyon hedefidir.

• Giriş denemelerini ve parola sıfırlama isteklerini oranla sınırlayın.
• Toplu atama/dışa aktarma gibi yönetici eylemlerini oranla sınırlandırın.
• Şüpheli sıçramalar için uyarılar ekleyin (kısa sürede çok sayıda izin değişikliği gibi).

Mümkünse, riskli eylemler için adım yükseltme doğrulaması isteyin (yeniden kimlik doğrulama veya ek onay gibi).

Sırlar, şifreleme ve en az ayrıcalık

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.

• Hassas verileri disk üzerinde ve iletimde şifreleyin (her yerde TLS).
• Veritabanı ve servis hesapları için en az ayrıcalıklı izinler kullanın: web uygulaması sadece ihtiyaç duyduğu minimum izinlere sahip olsun.
• Raporlama ve audit exportları için mümkünse "okuma" ve "yazma" kimlik bilgilerini ayırın.

Hızlı tehdit kontrolleri (ne test edilmeli)

Düzenli olarak test edin:

• Ayrıcalık yükselmesi (bir kullanıcının kendisine veya takımına erişim vermesi)
• IDOR sorunları (URL'deki bir ID'yi değiştirerek başka takımın verilerine erişim)
• "Dahili" endpointlerde eksik yetkilendirme
• Tehlikeli varsayılanlar (yeni entegrasyonların otomatik geniş erişim alması)

Bu kontroller ucuzdur ve izin sistemlerinin en yaygın hatalarını yakalar.

İzin ağırlıklı uygulamalar için test stratejisi

İ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.

1) Kuralları birim testleriyle test edin (hızlı geri bildirim)

İzin değerlendiricinizi (allow/deny kararını veren fonksiyon) birim testleriyle başlayarak test edin. Testleri senaryo isimlendirmesiyle okunur tutun.

• Kullanıcı askıya alınmışsa, araç arşivlenmişse, rol oturum ortasında silinmişse gibi kenar durumları dahil ederek hem izin veren hem reddeden durumları test edin.
• İstisna yollarını ekleyin: geçici erişim, break-glass admin, kendi kendine hizmet ama onay gerektiren eylemler.

İyi bir desen, küçük bir vaka tablosu (kullanıcı durumu, rol, kaynak, eylem → beklenen karar) tutmaktır.

2) Yüksek riskli yolculuklar için entegrasyon testleri

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:

• Erişim isteği → onaycı onaylar/ret → kullanıcı erişimi kazanır/kaybeder
• Rol değişikliği → erişimde anlık etki
• Kullanıcı deprovision → her yerde erişim kaldırılır

Bu testler UI'nin kullandığı aynı endpointlere isabet ederek API cevaplarını ve veritabanı değişikliklerini doğrulamalıdır.

3) Güvenilir test fixture'ları

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.

4) Her sürüm öncesi regresyon kontrol listesi

İ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.

Dağıtım, izleme ve operasyonlar

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.

Ortamlarınızı planlayın (dev, staging, prod)

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:

• Audit günlükleri (test gürültüsü uyumluluk raporlarını kirletmesin)
• Onay iş akışları (staging onayları gerçek onaycıları bildirmesin)
• Gizli anahtarlar (prod imza anahtarlarını alt ortamlarda yeniden kullanmayın)

Erken yakalayan izleme

Uptime ve gecikme gibi temel metriklerin yanına izin-özel sinyaller ekleyin:

• Türüne göre kimlik doğrulama hataları: oturum süresi doldu vs SSO hata vs eksik izin
• Bir araç/takım için yetkilendirme reddi sıçramaları (genelde bir rol eşlemesinin bozulduğunu gösterir)
• Şüpheli modeller: tekrarlayan erişim istekleri, hızlı rol değişimleri, olağandışı yönetici etkinliği

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.

2'de sabah için çalışma kitapları

Yaygın acil durumlar için kısa runbook'lar yazın:

• Erişimi hızlı iptal et (kullanıcıyı devre dışı bırak, rol bağlamalarını kaldır, oturumları geçersiz kıl)
• Servisi geri yükle (bir politika değişikliğini geri al, fail-closed vs fail-open karar ver, anahtarları rotasyon yap)
• SSO kesintisi prosedürü (zaman sınırlı break-glass erişim ile)

Runbook'ları repoda ve operasyon wikinizde tutun; tatbikatlarda test edin.

Yönetişim atlamadan daha hızlı inşa etmek

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.

Sonraki adımlar

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.