Harici Danışman Erişimi İçin Web Uygulaması Nasıl Oluşturulur?

“Danışman Erişimi” Gerçekte Ne Anlama Gelir

“Danışman erişimi”, çalışan olmayan kişilerin sistemlerinizde gerçek işler yapmasına izin veren izinler ve iş akışları kümesidir—onları zaman içinde ayrıcalık biriktiren kalıcı kullanıcılara dönüştürmeden.

Danışmanların genellikle ihtiyaç duyduğu erişim:

• Harici (ayrı bir kimlik olarak doğrulanırlar, ortak bir ekip oturumu değil)
• Projeye bağlı (belirli bir müşteri, proje veya görevle ilişkilidir)
• Zamana bağlı (yenilenmedikçe otomatik olarak sona ermeli)
• Denetlenebilir (her eylem bir kişiye ve onaya izlenebilir)

Çözdüğünüz problem

Çalışanlar İK yaşam döngüsü ve dahili BT süreçleriyle yönetilir. Danışmanlar genellikle bu mekanizmanın dışında kalır, ancak yine de hızlı erişime ihtiyaç duyarlar—bazen birkaç gün, bazen bir çeyrek için.

Danışmanları çalışan gibi ele alırsanız, yavaş işe alım ve dağınık istisnalar elde edersiniz. Onları rahat ele alırsanız, güvenlik açıkları oluşur.

Tasarım yaparken karşısına çıkmanız gereken yaygın riskler

Varsayılan başarısızlık modu aşırı yetkilendirmedir: biri işi başlatmak için “geçici” geniş erişim verir ve bu erişim asla azaltılmaz. Eski hesaplar ikinci sıradadır: sözleşme bittikten sonra erişim açık kalır. Paylaşılan kimlik bilgileri en kötüsüdür: kimlik doğrulama kaybolur, kimin ne yaptığı kanıtlanamaz ve offboarding imkansızlaşır.

Danışman erişim web uygulaması için hedefler

Uygulamanız şunları optimize etmelidir:

• Hızlı işe alım: net bir sahip ve az tekrar gerektiren süreçle
• Asgari ayrıcalık varsayılanı (erişim dar başlar, sadece gerekçe ile genişler)
• Net sorumluluk (istek sahibinin, onaylayanın ve danışmanın kimliği açık)
• Kolay offboarding: her yerde erişimi güvenilir şekilde kaldırır

Uygulamanın yönetmesi gerekenler (kapsam)

Organizasyonunuzda “erişim”in neyi kapsadığını açıkça belirtin. Yaygın kapsam:

• Uygulamalar (iç araçlar, ticket sistemleri, panolar)
• Veri (veri setleri, dosyalar, kayıtlar, dışa aktarımlar)
• Ortamlar (prod vs. staging vs. dev)
• Müşteriler/projeler (bir danışmanın hangi müşteri verisini hangi rol ile görebileceği)

Danışman erişimini kurallar içeren bir ürün yüzeyi olarak tanımlayın—rastgele yönetim işi olarak değil—ve diğer tasarım kararları çok daha kolaylaşır.

Gereksinimler Kontrol Listesi ve Paydaşlar

Ekranları tasarlamadan veya bir kimlik sağlayıcı seçmeden önce kimin erişime ihtiyacı olduğunu, neden ve nasıl sona ereceğini netleştirin. Harici danışman erişimi en sık gereksinimler yazılmadığı için başarısız olur.

Paydaşlar (ve her birinin önemsediği şeyler)

• İç sponsor (proje sahibi): danışmanın çabuk üretken olmasını ister, ekstra destek işi yaratılmadan.
• BT/Güvenlik yöneticisi: politikaları (SSO/MFA beklentileri, kayıt, zaman sınırları) uygulamak ve olaylara yanıt vermek için tutarlı bir yol ister.
• Danışman (harici kullanıcı): basit bir giriş ve sadece teslimatlar için gereken araç/veri gerekir.
• Onaylayıcı (yönetici, müşteri lideri veya veri sahibi): erişim taleplerinin meşru ve doğru projeyle sınırlı olduğunu görmek ister.

Kimlerin neyi onaylayabileceğini erkenden netleştirin. Yaygın bir kural: proje sahibi projeye erişimi onaylarken, BT/güvenlik istisnaları (örn. yükseltilmiş roller) onaylar.

Uçtan uca desteklenecek temel iş akışı

“Mutlu yol”unuzu bir cümleyle yazın, sonra genişletin:

Talep → onay → sağlama → inceleme → iptal

Her adım için şunları yakalayın:

• Hangi bilgilerin sağlanması gerekiyor (proje, rol, başlangıç/bitiş tarihi, gerekçe)
• Kim sorumlu (istek sahibi vs. sponsor vs. BT/güvenlik)
• Beklenen dönüş süresi (aynı gün, 24 saat, 3 iş günü)
• Başarısızlık durumunda ne olur (eksik bilgi, reddedilen istek, süresi dolan pencere)

Belgelemeniz gereken kısıtlar

• Birden fazla müşteri/proje: bir danışman birden fazla projede çalışabilir—müşteri verileri arasında çapraz görünüm olmamalı.
• Sınırlı zaman pencereleri: erişim otomatik olarak sona ermeli, net bir yenileme süreci olmalı.
• Uyumluluk ihtiyaçları: onayların ve denetim geçmişinin saklanması, periyodik incelemelerin kanıtı, sözleşme bittiğinde hızlı iptal.
• Destek modeli: kim erişimi sıfırlar, kilitli hesapları kim yönetir ve “neden bunu göremiyorum?” sorusuna kim cevap verir.

Başarı metrikleri (işlediğini kanıtlamak için)

Birkaç ölçülebilir hedef seçin:

• İşe alım süresi (istek gönderildi → erişim kullanılır halde)
• % hesapların planlı incelenmesi (aylık/çeyreklik erişim incelemeleri)
• İptal süresi (fesh/kontrat sonu → her yerde erişim kaldırıldı)

Bu gereksinimler, portal, onaylar ve yönetişim için kabul kriterleriniz olur.

Veri Modeli: Kullanıcılar, Projeler, Roller ve Politikalar

Temiz bir veri modeli, “danışman erişiminin” tek seferlik istisnalara dönüşmesini engeller. Amacınız birinin kim olduğunu, neye dokunabileceğini ve nedenini temsil etmek—aynı zamanda zaman sınırları ve onayları birinci sınıf kavramlar haline getirmektir.

Temel nesneler (sakladığınız şeyler)

Küçük bir dayanıklı nesne seti ile başlayın:

• Kullanıcılar: hem çalışanlar hem de harici danışmanlar. Kimlik özniteliklerini (e-posta, ad), kullanıcı tipi (dahili/harici) ve durumu içirin.
• Organizasyonlar: danışman firması ve gerekiyorsa iç iş birimleri.
• Projeler: erişimin verildiği iş birimi (müşteri hesabı, görev, dava, site).
• Kaynaklar: korunan şeyler (dokümanlar, ticketlar, raporlar, ortamlar). Bunları türlendirilmiş kayıtlar veya bir "resource" tipi alanı ile modelleyebilirsiniz.
• Roller: insan tarafından anlaşılabilir yetki paketleri (ör. “Consultant Viewer”, “Consultant Editor”, “Finance Approver”).
• Politikalar: rolleri sınırlayan kurallar (izin verilen kaynak türleri, veri kapsamı, IP/cihaz gereksinimleri, zaman sınırları).

İlişkiler (erişim nasıl ifade edilir)

Çoğu erişim kararı ilişkilerde toplanır:

• Kullanıcı ↔ Proje üyeliği: bir project_memberships gibi bir ilişki tablosu kullanarak bir kullanıcının bir projeye ait olduğunu belirtin.
• Rol atamaları: bir kullanıcının bir kapsam içinde rol verdiği role_assignments gibi ayrı bir ilişki tablosu.
• İstisnalar: bunları açıkça modelleyin (örn. policy_exceptions) ki daha sonra denetlenebilsinler, ad-hoc bayraklara gömülmesinler.

Bu ayrım, “Hangi danışmanlar Proje A'ya erişebilir?” “Bu kullanıcının hangi rolleri var ve nerede?” “Hangi izinler standart, hangi istisna?” gibi sorulara cevap vermenizi sağlar.

Zaman sınırlı erişim (geçici varsayılan olsun)

Model, geçici erişimi zorladığında yönetimi kolaylaşır:

• Üyeliklerde ve/veya rol atamalarında başlangıç/bitiş zaman damgaları ekleyin.
• Yenileme kurallarını saklayın (kim yenileyebilir, maksimum süre, yenileme sayısı).
• Kısa bir devretme penceresi istiyorsanız bir hoşgörü (grace period) alanı ekleyin (örn. 48 saat için salt okunur).

Durum değişiklikleri (yaşam döngüsünü izleyin)

Üyelikler/atanmalar için sadece “silindi” demek yerine net bir durum alanı kullanın:

• pending (istek yapıldı, henüz onaylanmadı)
• active
• suspended (geçici engellendi)
• expired (bitiş tarihi geçti)
• revoked (yöneticinin erkenden sona erdirdiği)

Bu durumlar iş akışlarını, UI'yı ve denetim günlüklerini tutarlı yapar—ve “hayalet erişimi” önler.

Erişim Kontrol Tasarımı (RBAC + Koruyucu Önlemler)

İyi danışman erişimi nadiren “her şey ya da hiç”tir. Net bir temel (kim ne yapabilir) artı koruyucu önlemler (ne zaman, nerede ve hangi koşullar altında) gerekir. Birçok uygulama burada başarısız olur: roller uygular ama bu rolleri gerçek hayatta güvenli tutan kontrolleri atlar.

RBAC ile başlayın: proje başına basit roller

Rol bazlı erişim kontrolünü (RBAC) temel olarak kullanın. Rolleri anlaşılır ve belirli bir proje veya kaynağa bağlı tutun, uygulama çapında global yapmayın.

Yaygın temel:

• Viewer: proje verilerini okuyabilir, onaylı materyalleri indirebilir.
• Editor: projede öğe oluşturma/güncelleme yapabilir (teslimat yükleme, yorum, durum güncelleme).
• Admin: proje ayarlarını yönetebilir ve o proje için roller atayabilir.

“Kapsam”ı açık yapın: Proje A'da Viewer olmak Proje B hakkında hiçbir şey ifade etmez.

ABAC tarzı koşullarla koruyucular ekleyin

RBAC “ne yapabilir?”i cevaplar. Koruyucular “hangi koşullar altında izinli?” sorusunu cevaplar. Risk daha yüksek veya gereksinimler değişkense öznitelik temelli kontroller (ABAC tarzı) ekleyin.

Sık uygulanmaya değer koşul örnekleri:

• Proje öznitelikleri: sadece danışmanın atanmış müşteri hesabı veya bölgesi içindeki projelere izin verin.
• Konum/ağ: hassas dışa aktarımlar için güvenilir ağ gerektirin (veya yüksek riskli coğrafyaları engelleyin).
• Cihaz durumu: oturum güven şartlarını karşılamayan cihazlarda işlemleri kısıtlayın (örn. MFA tamamlandı, yönetilen cihaz).
• Zaman pencereleri: erişimi yalnızca görev tarihleri veya mesai saatleriyle sınırlayın.

Bu kontroller katmanlanabilir: bir danışman Editor olabilir, ama veri dışa aktarma için hem güvenilir cihazda olma hem de onaylı bir zaman penceresinde olma gerekebilir.

Varsayılan asgari ayrıcalık, istisnalar süreçle

Her yeni harici kullanıcıyı en düşük role (genellikle Viewer) ve minimal proje kapsamına alın. Daha fazlasına ihtiyaç varsa bir istisna talebi zorunlu kılın:

• gereken spesifik izin(ler),
• etkilenen proje(ler),
• yazılı gerekçe,
• bir bitiş tarihi.

Bu, “geçici” erişimin sessizce kalıcı olmasını engeller.

Break-glass erişimi (ve kontrolü)

Acil durumlar için bir break-glass yolu tanımlayın (örn. üretim olayı). Nadir ve açık olsun:

• onay, atanmış nöbet sahibi tarafından veya yüksek riskli işlemler için iki kişilik onay ile verilsin,
• zaman sınırlı olsun (dakikalar/saatler, günler değil),
• kim, ne, ne zaman ve neden tam olarak loglansın.

Break-glass rahatsız edici hissettirmeli—çünkü kısa yol değil, bir güvenlik valfidir.

Kimlik Doğrulama: SSO, MFA ve Güvenli Oturum İşleme

Kimlik doğrulama, “harici” erişimin ya sorunsuz hissettirdiği ya da kalıcı bir risk haline geldiği yerdir. Danışmanlar için sürtünme sadece gerçek maruziyeti azaltıyorsa olmalı.

Kimlik yaklaşımınızı seçin: yerel hesaplar vs SSO

Yerel hesaplar (e-posta + şifre) hızlıdır ve herhangi bir danışman için çalışır, ancak parola sıfırlama desteği gerektirir ve zayıf kimlik bilgileri riski artar.

SSO (SAML veya OIDC) genellikle danışmanın firması bir kimlik sağlayıcısına sahipse en temiz seçenek olur (Okta, Entra ID, Google Workspace). Merkezi giriş politikaları, kendi taraflarında daha kolay offboarding ve sisteminizde daha az parola sağlanır.

Pratik bir desen:

• Danışmanın şirketi entegre ise SSO'yu varsayılan yapın.
• Bağımsız danışmanlar için yerel hesaplara düşüş (fallback) sağlayın.

Her iki yönteme izin verirseniz, hangi yöntemin o kullanıcı için aktif olduğunu açık gösterin ki olay yanıtlamada kafa karışıklığı olmasın.

MFA: “gösteriş” olmadan (ve zayıf kurtarmadan kaçının)

Tüm danışman oturumları için MFA zorunlu kılın—tercihen kimlik doğrulayıcı uygulamalar veya güvenlik anahtarları. SMS yedek olsun, birincil seçenek olmasın.

Kurtarma, birçok sistemi kazayla zayıflatan noktadır. Kalıcı “yedek e-posta” atlamalarından kaçının. Bunun yerine daha güvenli sınırlı seçenekler kullanın:

• Kayıt sırasında bir kere gösterilen tek kullanımlık kurtarma kodları
• Kimlik doğrulaması gerektiren ve tam olarak loglanan yönetici destekli sıfırlama
• MFA'yı yeniden zorlayan cihaz yeniden kayıt süreci

Davet akışları: süresi dolan bağlantılar ve domain kontrolleri

Çoğu danışman davetle katılır. Davet bağlantısını geçici bir kimlik gibi ele alın:

• Kısa süreli geçerlilik (örn. 24–72 saat)
• Tek kullanımlık, davet edilen e-posta adresine bağlı
• Hız sınırlaması ve açıklayıcı hata mesajları

Her müşteri veya proje için alan izin/engelleme listeleri ekleyin (örn. @partnerfirm.com izinli; gerektiğinde ücretsiz e-posta domainlerini engelle). Bu, yanlış hedeflenmiş davetlerin kazara erişime dönüşmesini önler.

Oturum güvenliği: kısa ömürlü ve iptal edilebilir tokenlar

Danışmanlar genellikle paylaşılan makineler kullanır, seyahat eder ve cihaz değiştirir. Oturumlarınızı bu gerçekliği varsayacak şekilde düzenleyin:

• Kısa ömürlü erişim tokenları kullanın
• Yenileme tokenlarını döndürün ve şüpheli etkinlikte iptal edin
• Kullanıcılar ve yöneticiler için “tüm cihazlardan çıkış yap” seçeneği sunun

Oturum geçerliliğini rol değişiklikleri ve onaylarla ilişkilendirin: erişim azaltıldığında veya süresi dolduğunda aktif oturumlar hızla sona ermeli, bir sonraki girişe kadar beklememeli.

Talep ve Onay İş Akışı

Temiz bir talep-ve-onay akışı, “hızlı iyilikler”in kalıcı, belgesiz erişime dönüşmesini engeller. Her danışman erişim talebini küçük bir sözleşme gibi ele alın: net kapsam, net sahip, net bitiş tarihi.

Talep formu: niyeti yakalayın, sadece kimliği değil

Formu istekte bulunanların belirsiz olmasını engelleyecek şekilde tasarlayın. En azından şunları zorunlu kılın:

• Proje (veya müşteri görevi)
• İstenen rol (standart rollerle eşlenen, serbest metin değil)
• Süre (başlangıç ve bitiş tarihi, açık zaman dilimi ile)
• İş gerekçesi (erişim olmadan hangi iş engellendiğini açıklayan bir paragraf)

Birden fazla projeye izin veriyorsanız, formu proje-özgü yapın ki onaylar ve politikalar karışmasın.

Onay yönlendirme: sahipliği açık yapın

Onaylar organizasyon şeması yerine sorumluluğa göre gitmeli. Yaygın yönlendirme:

• Proje sahibi (danışmanın projede çalışması gerektiğini onaylar)
• Güvenlik ya da BT (rolün uygun olduğunu ve asgari ayrıcalıkla uyumlu olduğunu teyit eder)
• Müşteri irtibatı (varsa, üçüncü taraf erişimini müşteri onaylamalıdır)

E-posta ile onaylamadan kaçının. Verilecek izinleri ve süresini gösteren uygulama içi onay ekranı kullanın.

SLA'lar, hatırlatmalar ve tırmanma

Taleplerin takılı kalmaması için hafif otomasyon ekleyin:

• Bekleyen onaylar için hatırlatmalar (örn. 24 saat sonra)
• Yaklaşan süre sonları için bildirimler (örn. bitişten 7 gün önce)
• Birincil onaylayıcı yoksa alternatif onaylayıcıya tırmanma

Her kararı kaydedin

Her adım değişmez ve sorgulanabilir olmalı: kim onayladı, ne zaman, ne değişti ve hangi rol/süre yetkilendirildi. Bu denetim izi incelemeler, olaylar ve müşteri sorularında sizin tek kaynak bilginiz olur.

Sağlama ve Zaman-Sınırlı Erişim

Sağlama, “kâğıt üzerindeki onay”ın üründe kullanılabilir hale gelmesidir. Harici danışmanlar için hedef hızdır ama aşırıya kaçılmaması: sadece gereken verilmelidir, sadece gerektiği kadar süreyle ve iş değiştiğinde değişiklik yapmak kolay olmalıdır.

Varsayılan yolu otomatikleştirin

Onaylanmış isteğe bağlı tutarlı, otomatik bir akışla başlayın:

• Rol ataması: her onaylanan görev türünü bir role eşleyin (örn. Finance Analyst – Read Only, Implementation Partner – Project Admin).
• Grup üyeliği: danışmanı doğru gruplara ekleyin ki izinler projeler arasında tutarlı kalsın.
• Kaynak izinleri: otomatik olarak yalnızca belirtilen projelere, çalışma alanlarına veya veri setlerine erişim verin—tüm kiracıya değil.

Otomasyon idempotent olmalı (iki kere çalıştırılsa bile güvenli) ve ne verildiğini gösteren bir “sağlama özeti” üretmeli.

Manuel adımları destekleyin (kontrol listeleriyle)

Bazı izinler uygulamanız dışında yaşar (paylaşılan sürücüler, üçüncü taraf araçlar). Otomasyon mümkün olmadığında manuel işi güvenli hale getirin:

• Sahip, bitiş tarihi ve doğrulama ile bir adım adım kontrol listesi sağlayın (örn. “Klasör erişimini doğrula”, “VPN profilini onayla”).
• Gerçekleştirenin her adımı tamamlandı olarak işaretlemesi ve gerektiğinde kanıt (ticket bağlantısı, ekran görüntüsü, sistem kayıt ID'si) yakalaması zorunlu olsun.

Zaman-sınırlı erişim ve yenileme uyarıları

Her danışman hesabı oluşturulurken bir bitiş tarihi olmalı. Uygulayın:

• Otomatik sona erme: erişim bitişte otomatik olarak iptal edilir (teorik olarak “devre dışı bırakılmak” değil).
• Yenileme bildirimleri: danışmanı ve iç sponsoru önceden (örn. 14 gün ve 3 gün kala) bir tıklamayla yenileme talebi gönderecek şekilde bilgilendirin.
• Hoşgörü kuralları: sessiz uzatmalardan kaçının; çalışma devam edecekse aynı onay mantığıyla ilerlesin.

Ara-dönem değişiklikleri: yükseltmeler, kapsam değişimleri, askıya alma

Danışman işi evrilebilir. Güvenli güncellemeleri destekleyin:

• Rol yükseltme/düşürme gerekçe ve onay iziyle.
• Kapsam değişiklikleri (proje ekle/çıkar) yeniden işe alım olmadan.
• Askıya almalar (güvenlik incelemesi, sözleşme boşluğu) erişimi hemen kaldırır ama geçmişi korur.

Denetim Günlükleri, İzleme ve Uyarılar

Denetim günlükleri harici erişim için “kâğıt izi”dir: kimin ne yaptığını, ne zaman ve nereden açıkladığıdır. Danışman erişim yönetimi için bu yalnızca uyumluluk kutusunu işaretlemek değildir—olayları soruşturmanın, asgari ayrıcalığı kanıtlamanın ve anlaşmazlıkları hızlı çözmenin yoludur.

Pratik bir denetim günlüğü şeması

Uygulama genelinde çalışan tutarlı bir olay modeli ile başlayın:

• actor: işlemi başlatan (kullanıcı ID, rol, org)
• target: etkilenen nesne (proje ID, dosya ID, kullanıcı ID)
• action: kanonik fiil (INVITE_SENT, ROLE_GRANTED, DATA_EXPORTED)
• timestamp: sunucu tarafı zaman (UTC)
• ip: kaynak IP (mümkünse user agent ile)
• metadata: bağlam için JSON (policy ID, önceki/yeni değerler, gerekçe kodları, ticket)

Eylemleri standartlaştırın ki raporlama kâbusu olmasın.

Loglanması gereken olaylar (asgari set)

Hem “güvenlik olaylarını” hem de “işe etki eden olayları” kaydedin:

• Davet gönderildi/kabul edildi/süresi doldu, hesap aktivasyonu, parola sıfırlama
• Girişler, çıkışlar, oturum yenileme, başarısız giriş denemeleri
• MFA kayıt/değişiklikleri, MFA hataları, SSO doğrulama hataları
• Rol veya politika değişiklikleri (kim onayladı ve neden)
• Hassas görünümler, dışa aktarımlar/indirmeler ve API anahtarı kullanımı
• Yönetici eylemleri: kullanıcı devre dışı bırakma, proje yeniden atama, toplu değişiklikler

İzleme ve uyarı tetikleyicileri

Denetim günlükleri, uyarılarla birleşince daha faydalı olur. Yaygın tetikleyiciler:

• Olağandışı giriş desenleri (yeni ülke/cihaz, imkansız seyahat, mesai dışı ani artış)
• Tekrarlayan başarısız MFA veya giriş denemeleri (hesap ele geçirme riski)
• Yetki yükseltme (danışman rolünün yükseltilmesi, yeni admin verilmesi)
• Kısıtlı projelerden büyük veya tekrarlayan dışa aktarımlar

Dışa aktarma ve saklama

Filtrelerle (tarih aralığı, actor, proje, eylem) CSV/JSON dışa aktarma sağlayın ve saklama ayarlarını politikalara göre belirleyin (örn. varsayılan 90 gün, düzenlenen ekipler için daha uzun). Denetim dışa aktarımlarına erişimi ayrıcalıklı bir eylem olarak belgeleyin (ve onu da loglayın). İlgili kontroller için /security bölümüne bakın.

Erişim İncelemeleri ve Sürekli Yönetişim

Erişim vermek işin yarısıdır. Gerçek risk zaman içinde sessizce büyür: danışman proje bitirir, takımlar değişir veya oturum açmaz—ama hesapları çalışmaya devam eder. Sürekli yönetişim, “geçici” erişimin kalıcı olmasını engeller.

İnsanların gerçekten kullanacağı inceleme panelleri oluşturun

Sponsorlar ve proje sahipleri için şu soruları her seferinde cevaplayan basit bir inceleme görünümü oluşturun:

• Proje ve role göre aktif danışmanlar
• Son aktivite (ve ilgiliyse son hassas eylem)
• Erişim bitiş tarihi ve kalan süre
• Bekleyen onaylar, yenilemeler ve istisnalar

Panoyu odaklı tutun. Bir gözden geçiren “sakla” veya “kaldır” diyebilmeli, beş farklı sayfa açmak zorunda kalmamalı.

Atamalar ekleyin (sahip onayı)

Yüksek riskli sistemler için aylık, daha düşük riskliler için çeyreklik atamalar planlayın; sahip her danışmanın hâlâ erişime ihtiyacı olup olmadığını onaylasın. Kararı açık yapın:

• Yenile (belirli süreyle, örn. 30/60/90 gün)
• Rol düşür
• Erişimi iptal et

İş yükünü azaltmak için varsayılanı “onaylanmazsa sona erer” şeklinde yapın. Onaylayan, ne zaman ve ne kadar süreyle onayladığını kaydetsin.

Çalışmayı bozmadan etkinliksizlik kuralları kullanın

Etkinliksizlik güçlü bir sinyaldir. “X gün oturum açmadığında askıya al” gibi kurallar uygulayın ama nazik bir süreç ekleyin:

1. Askıya almadan önce sponsor/ sahibi bilgilendirilsin
2. Bir tıklamayla “uzat” seçeneği verilsin ve yeni bir bitiş tarihi atanabilsin
3. Yanıt yoksa otomatik iptal olsun

Bu, sessiz riski önler ve sürpriz kilitlenmeleri engeller.

İstisnaları takip edin ve zamanlayın

Bazı danışmanlar olağandışı erişim isteyecektir. İstisnaları geçici tasarlayın: gerekçe, bitiş tarihi ve planlı yeniden gözden geçirme zorunlu olsun. Panonuz istisnaları ayrı göstererek unutulmamalarını sağlayın.

Eğer pratik bir sonraki adım isterseniz, yöneticilik alanınızdan (ör. /admin/access-reviews) yönetişim görevlerine bağlantı verin ve bunu sponsorlar için varsayılan açılış sayfası yapın.

Offboarding: Gerçekten Etkili İptal

Harici danışman offboarding’i sadece “hesabı devre dışı bırakmak” değildir. Sadece uygulama rolünü kaldırırsanız ama oturumları, API anahtarlarını, paylaşılan klasörleri veya sırları dokunulmamış bırakırsanız erişim sözleşme bittikten sonra da sürebilir. İyi bir web uygulaması offboarding’i tekrarlanabilir prosedür, net tetikleyiciler, otomasyon ve doğrulama ile ele alır.

Net offboarding tetikleyicileri tanımlayın

Offboarding akışını otomatik başlatacak olayları belirleyin. Yaygın tetikleyiciler:

• Sözleşme bitiş tarihi (önceden planlanmış)
• Proje tamamlanması (proje “kapalı” olarak işaretlendi)
• Politika ihlalleri (güvenlik olayı, başarısız erişim incelemesi, İK/hukuk talebi)

Sistem bu tetikleyicileri açık ve denetlenebilir yapmalı. Örn: bir sözleşme kaydı ile bitiş tarihi veya proje durum değişikliği bir "Offboarding required" görevi oluşturmalı.

Sadece “izinleri kaldırma” değil, iptali otomatikleştirin

Iptal kapsamlı ve hızlı olmalı. En azından otomatikleştirin:

• Kullanıcı hesabını devre dışı bırakın veya inaktif olarak işaretleyin
• Projeye, veriye veya yönetim işlevlerine izin veren tüm roller/grupları kaldırın
• Aktif oturumları ve tokenları iptal edin (web oturumları, refresh tokenlar, API tokenları)

SSO destekliyorsanız, SSO sonlandırması uygulamadaki mevcut oturumları her zaman yok etmeyebilir. Sunucu tarafı oturum geçersiz kılma yaparak danışmanın önceden kimlik doğrulanmış tarayıcıdan çalışmaya devam etmesini önleyin.

Veri devri ve sır temizliği

Offboarding aynı zamanda veri hijyenidir. Kişisel gelen kutularında veya özel sürücülerde bırakılmaması için bir kontrol listesi oluşturun.

Tipik maddeler:

• Teslimatlar ve çalışma ürünleri: proje alanına yüklensin ve iç bir kullanıcıya sahiplik verilsin
• Kimlik bilgisi döndürme: danışmanın bilebileceği tüm kimlik bilgileri (veritabanı parolaları, API anahtarları) döndürülsün
• Paylaşılan sırların temizliği: paylaşılan kasa girişlerinden, paylaşılan klasörlerden, dağıtım listelerinden ve sohbet kanallarından kaldırın

Portalınız dosya yükleme veya ticket içeriyorsa, içsel sahibine ilgili belgeleri ve bağlantıları içeren bir “Handover paketi dışa aktar” seçeneği düşünün.

Kapanışı son bir denetim kaydıyla doğrulayın

Etkili iptal doğrulama içerir. “Muhtemelen iyi” demeye güvenmeyin—kaydedin.

Kullanışlı doğrulama adımları:

• Danışmanın aktif rolünün sıfır olduğunu ve hiç proje üyeliği kalmadığını doğrulayın
• Tüm oturumların/tokenların iptal edildiğini ve geçerli token kalmadığını doğrulayın
• Son bir offboarding denetim olayı oluşturun (kim başlattı, ne zaman çalıştı, neler kaldırıldı, varsa istisnalar)

Bu son denetim girdisi, erişim incelemelerinde, olay soruşturmalarında ve uyumluluk kontrollerinde kullanacağınız güvenilir kayıttır.

Uygulama Planı: API'ler, UI, Test ve Dağıtım

Bu, erişim politikanızı çalışan bir ürüne dönüştürecek inşa planıdır: küçük bir API seti, basit bir yönetici/onaycı UI'si ve erişimin sessizce başarısız olmamasını sağlayacak yeterli test ve dağıtım hijyeni.

Hızlı bir ilk sürüm almak istiyorsanız, çalışma yazma (vibe-coding) yaklaşımı etkili olabilir: iş akışını, rolleri ve ekranları tanımlarsınız ve çalışan yazılımdan (wireframe yerine) yineleyerek ilerlersiniz. Örneğin, Koder.ai ekiplerin React UI, Go backend ve PostgreSQL içeren bir harici kullanıcı portalini sohbet bazlı bir spesifikasyondan prototiplemesine yardımcı olabilir; sonra onaylar, süre sonu işleri ve denetim görünümleri ile iyileştirme yapabilirsiniz.

API yüzeyi (sıkıcı ve tutarlı tutun)

Zaten tanımladığınız nesneler (kullanıcılar, roller, projeler, politikalar) ve iş akışı (istekler → onaylar → sağlama) etrafında endpointler tasarlayın:

• Users & roles: GET /api/users, POST /api/users, GET /api/roles, POST /api/roles
• Access requests: POST /api/access-requests, GET /api/access-requests?status=pending
• Approvals: POST /api/access-requests/{id}/approve, POST /api/access-requests/{id}/deny
• Provisioning/expiry: POST /api/grants, PATCH /api/grants/{id} (extend/revoke), GET /api/grants?expires_before=...
• Audit: GET /api/audit-logs?actor=...&project=... (salt okunur; günlükleri "düzenleme" yok)

UI tarafında üç ekran hedefleyin:

1. Danışman portalı (onun nereye eriştiğini, bitiş tarihini görme, erişim talep etme)
2. Onaycı gelen kutusu
3. Yönetici konsolu (roller, politikalar, izinler, denetim araması)

Her yerde uygulayacağınız güvenlik temelleri

Her yazma endpointinde girdi doğrulama yapın, cookie tabanlı oturumlar için CSRF koruması uygulayın ve giriş, istek oluşturma ve denetim aramasına hız sınırlaması ekleyin.

Dosya yüklemeyi destekliyorsanız (örn. iş tanımı belgeleri), izin verilen MIME türleri, virüs taraması, boyut sınırları ve rastgele isimlerle web kökünün dışında depolama kullanın.

Test planı (izin hatası ürün hatasıdır)

Kapsayın:

• İzin testleri: rol, proje ve politika kısıtlamalarıyla “yapabilir/yapamaz” testleri
• İş akışı testleri: istek → onay → sağlama oluştu → bildirimler
• Zaman bazlı sona erme: erişim sürede durur ve “uzatma” onay gerektirir

Dağıtım notları

Dev/stage/prod ayrımı yapın, gizli bilgileri bir kasada yönetin (env dosyalarını gitte saklamayın) ve yedekleri şifreleyin. Süre sonu/iptal için tekrarlayan bir görev ekleyin ve başarısız olursa uyarı üretin.

Eğer bir kontrol listesi eşlik etmesini isterseniz, ekibinizi /blog/access-review-checklist'e yönlendirin ve fiyatlama/paketleme ayrıntılarını /pricing bölümünde tutun.

Son kontrol listesi: "İyi" neye benzer

Bir danışman erişim web uygulaması her seferinde aynı sonuçları ürettiğinde amacına ulaşmış demektir:

• Her danışmanın benzersiz bir kimliği, MFA'sı ve projeye bağlı bir kapsamı vardır.
• Her erişim verme bir sahibi, bir onaylayıcı, bir gerekçe ve bir bitiş tarihi içerir.
• Süre sonu ve iptal otomatikleştirilmiştir (oturum/token geçersiz kılma dahil).
• İstisnalar görünür, zaman sınırlı ve tekrar gözden geçirilir.
• Olayları soruşturmak için yeterli tutarlılıkta loglar vardır.

Bu invariants'ları zorlayan en küçük sürümü inşa edin, sonra kullanım kolaylığı özelliklerinde (panolar, toplu işlemler, zengin politika seçenekleri) yineleyin—ana kontrolleri zayıflatmadan.