Mimari ve çalışma modeli
Landing zone, uygulama iş yüklerinden önce kurulan kimlik, hesap hiyerarşisi, ağ, loglama, güvenlik politikası ve maliyet yönetişimi temelidir. Google Cloud organization/folder/project; AWS Organizations OU/account; Azure tenant/management group/subscription yapıları benzer yönetim sorunlarını çözer fakat birebir aynı nesneler değildir.
Tek bir evrensel şablonu üç buluta kopyalamak yerine ortak kontrol hedeflerini tanımlayın: üretim ve test ayrımı, merkezi log, acil erişim, ağ çıkışı, anahtar yönetimi, bütçe alarmı ve politika istisnası. Her hedefi platformun yerel politika ve kimlik modeline çevirin. Ortak isimlendirme ve etiketler raporlamayı kolaylaştırır; platform farklarını saklamamalıdır.
Merkezi ağ hesabı her zaman doğru varsayım değildir. Uygulama ekiplerinin değişim hızı, veri yerleşimi, bölge bağımlılığı ve ortak hata alanı incelenmelidir. Organizasyon kökü veya yönetim hesabı günlük iş yükü çalıştırmamalı; ayrı güvenlik/log hesapları ve kontrollü break-glass erişimi kullanılmalıdır.
- 1Kurumsal kimlik ve hiyerarşi
- 2Politika ve ağ temeli
- 3Hesap/proje/subscription üretimi
- 4İş yükü kabulü
Tasarım parametreleri
- Hiyerarşi
- İş birimi, ortam ve veri sınıfını policy inheritance davranışıyla birlikte modelleyin.
- Kimlik
- İnsan erişimini federasyonla, iş yükü erişimini kısa ömürlü platform kimliğiyle ayırın.
- Ağ
- Hub-spoke, paylaşılan VPC/VNet ve transit seçeneklerini gecikme, ücret ve arıza alanıyla değerlendirin.
- Politika
- Preventive ve detective kontrolleri ayırın; istisnaya sahip, süre ve onay kaydı ekleyin.
Hesap ve uygulama örneği
Üç platformda prod, nonprod ve sandbox sınırları kurun. Ortak kontrol matrisi her platformda public object storage engeli, merkezi audit log ve aylık bütçe alarmı istesin. Ancak uygulama karşılıkları Google Cloud Organization Policy, AWS Control Tower/Organizations ve Azure Policy olsun.
On ekip ve üç bulut için 30 hesabı tek seferde açmak yerine bir uygulama pilotu seçin. Hesap açılış süresi, politika çakışması, log gecikmesi, private DNS ve acil erişim testlerini ölçün; sonra hesap fabrikasına dönüştürün.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
# Kontrol hedeflerini platform nesnesinden bağımsız envanterleyin.
control_id,scope,mode,owner,exception_expiry
LOG-001,all,audit,security,
NET-003,production,enforce,network,
COST-002,all,alert,finops,Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Yeni hesap politikaya uymuyor | Hesap yanlış OU/folder/management group altında veya bootstrap yarım kalmış. | Hiyerarşi yolunu, policy inheritance ve provisioning iş kaydını birlikte kontrol edin. |
| Merkezi log eksik | Log sink, trail veya diagnostic setting bölge/servis kapsamını kaçırmış olabilir. | Bir pilot olay üretip kaynak, taşıma ve hedefte aynı olay kimliğini izleyin. |
| Private servis adı çözümlenmiyor | Merkezi DNS ile spoke bağlantısı veya split-horizon kuralı eksik. | İstemcinin resolver yolunu, zone association ve forwarder logunu karşılaştırın. |
Kabul ve doğrulama kontrolleri
- Yeni hesap/proje/subscription için otomatik baseline doğrulayın.
- Yönetim kökünde günlük iş yükü olmadığını gösterin.
- Merkezi audit logun değiştirilemez hedefe ulaştığını test edin.
- Public erişim politikasını kontrollü ihlal denemesiyle sınayın.
- Break-glass hesabını alarm ve son kullanma süresiyle prova edin.
- Bütçe, etiket ve sahipsiz kaynak raporunu üç platformda üretin.
İlgili kavramlar
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.
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.
IT/OT güvenlik bölgeleri
Bölge, benzer güvenlik ve işletim gereksinimlerini paylaşan varlık grubudur; bölgeler arasındaki iletişim kontrollü geçitlerden geçmelidir. OT cihazının erişilebilir olması, tarama veya güncelleme için güvenli olduğunu göstermez. Kontrol gecikmesi, emniyet, üretici desteği ve bakım penceresi kararları değiştirir. PLC ve SCADA iletişimini mevcut üretim akışından gözlemleyin; IT tarafındaki politikayı olduğu gibi aktarmayın. Uzaktan destek erişimine kimlik, süre, onay ve kayıt koşulları tanımlayın. Aktif test ve geçişleri üretim sorumlusuyla koordine edin.
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.
Maliyet ölçümünün sınırı
Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayı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.