Kurulum · Kurumsal E-posta ve İş Birliği
Workspace ve Microsoft 365 için OAuth Uygulama Onay Kontrolü
OAuth uygulaması kullanıcı parolasını bilmeden izin verilen verilere erişebilir. Uygulama onayı, kullanıcının oturum açmasıyla aynı karar değildir. Delegated izin kullanıcı bağlamında,…
Teknik gözden geçirme:
Mimari ve çalışma modeli
OAuth uygulaması kullanıcı parolasını bilmeden izin verilen verilere erişebilir. Uygulama onayı, kullanıcının oturum açmasıyla aynı karar değildir. Delegated izin kullanıcı bağlamında, application izin uygulama kimliğiyle farklı kapsama ulaşabilir; bu ayrımı özellikle Microsoft 365 değerlendirmesinde kaydedin.
Önce OAuth client ID, istenen scope, üretici, veri ihtiyacı ve mevcut kullanıcı sayısını çıkarın. Google Workspace’te API controls/app access bölümünde pilot OU veya desteklenen kapsam üzerinden kısıtlama tanımlayın. Entra’da user consent politikasını ve admin consent sürecini uygulama bazında değerlendirin.
Üretimde tüm uygulamaları bir anda engellemek iş akışlarını durdurabilir. Önce salt okunur scope isteyen bir pilot ve gereksiz geniş scope isteyen negatif pilot kullanın. Mevcut grant/token davranışını ayrıca sınayın; yeni onayı kapatmak eski tüm erişimi otomatik iptal etmeyebilir.
- 1Uygulama ve scope
- 2İş ihtiyacı incelemesi
- 3Pilot onay politikası
- 4Grant iptal ve audit
Tasarım parametreleri
- Scope gereksinimi
- İşlev için gereken en dar API kapsamını seçin; tüm Drive veya mail erişimini gerekçesiz kabul etmeyin.
- Onay sahibi
- İş sahibi, teknik inceleyen ve güvenlik onayını ayrı kaydedin.
- Mevcut grant
- Politika değişikliğinde mevcut refresh token ve servis erişiminin durumunu kontrol edin.
Hesap ve uygulama örneği
Bir raporlama uygulaması yalnız belirli takvim verisini okumalıysa mail gönderme izni istemesi kapsam uyuşmazlığıdır. Pilot kullanıcısında gerekli işlevi dar izinle test edin. Uygulamayı kaldırınca hedef API çağrısının gerçekten reddedildiğini doğrulayın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Yeni politika eski erişimi durdurmadı | Önceden verilmiş grant veya farklı kimlik. | Token türünü ve mevcut permission grant’ı kontrol edin. |
| Pilot işlev bozuldu | Gerekli scope engellenmiş. | Başarısız API ve scope eşleşmesini inceleyin. |
Kabul ve doğrulama kontrolleri
- Client ID’yi doğrulayın.
- Scope ihtiyacını yazın.
- Dar pilot kullanıcı grubu seçin.
- Gereksiz izni reddedin.
- Mevcut grant iptalini sınayın.
- Onay/iptal kayıtlarını denetleyin.
İlgili kavramlar
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACLleri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
En az ayrıcalık ve görev ayrımı
En az ayrıcalık, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Politikanın yaşam döngüsü
Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.