Site yayına alınmış ve içerik ekibi güncelleme yapabiliyor olabilir. Yine de alan adının hangi hesapta kayıtlı olduğu, DNS değişikliğini kimin onayladığı veya kurtarma e-postasının kime gittiği bilinmiyorsa teslim tamamlanmış sayılmaz. Site çalışırken kritik kontrol tek bir dış hesapta kalabilir. Bu rehber, ekip değişiminde işletmenin erişimini ve devamlılığını doğrulamasına yardımcı olur.

Amaç parola listesi istemek veya bütün erişimi hemen kapatmak değildir. Hangi hesapların işletmeye ait olduğunu, ajansın hangi iş için yetkilendirildiğini ve devrin hangi kanıtla tamamlanacağını belirleyin. Web tasarım ve yazılım hizmeti kapsamını değerlendirirken bu ayrımları teklif ve destek aşamalarında da konuşun.

Teslimi dosya paylaşımı değil kontrolün doğrulanması olarak görün

Dosyaların yüklenmesi, yönetim panelinin gösterilmesi veya geçici parola verilmesi bağımsız sürdürülebilirliği kanıtlamaz. İşletme sorumlusu kendi hesabıyla giriş yapabilmeli; yenileme ve kurtarma bilgisini bulmalı, yetkileri açıklayabilmeli ve sağlayıcının resmî desteğine ulaşabilmelidir. Zararsız kontrolü önizlemede veya güvenli kopyada yapın.

İşletmenin her teknik işlemi kendisinin yapması gerekmez. Ajans bakım ve DNS görevlerini sürdürebilir. Ancak erişim, görev sınırı ve sorumluluk yazılı olmalı; dış ekip ayrıldığında başka yetkiliye geçiş yolu bilinmelidir.

Hesap envanterini görev ve sorumluya göre çıkarın

Siteyi çalıştıran parçaları e-posta yazışmalarından tahmin etmeyin; adlarıyla listeleyin. Alan adı kayıt şirketi, DNS, barındırma, CMS, kod deposu, yayın yöntemi, yedek, ölçüm aracı ve kurumsal e-posta farklı hesaplarda olabilir. Her satıra şunları yazın:

Hizmetin adı, giriş adresi ve işletme adına görünen kayıt ya da fatura bilgisi.
İşletmedeki birincil sorumlu, yedek sorumlu ve dış ekibin yaptığı görev.
Kurtarma e-postası veya telefonu, yenileme tarihi ve faturanın kime ulaştığı.
Verilen rolün kapsamı, erişimin ne zaman gözden geçirileceği ve iş bitince nasıl kaldırılacağı.

Envanterde parola, tek kullanımlık kod veya kurtarma anahtarı tutmayın; bunlar için güvenli kasayı ve yetkili kişileri ayrıca belirleyin. Kayıt, işletmenin hangi hizmete hangi hesapla eriştiğini göstermelidir.

Alan adı, DNS ve barındırmayı birbirinden ayırın

Alan adı kaydı kayıt şirketi ve kayıt sahibi bilgilerini; DNS, web ve e-posta trafiğinin yönünü; barındırma ise uygulamanın çalıştığı hizmeti kapsar. Bunlar farklı katmanlardır. Yeni sunucuya geçmek için kayıt şirketini değiştirmek her zaman gerekmez; alan adı aktarımı da tek başına barındırma değişikliği değildir.

Devirden önce DNS kayıtlarının kimde olduğunu, nasıl yedeklendiğini ve e-posta üzerindeki etkisini yazın. Kayıt şirketi değişecekse uzantı ve sağlayıcının güncel onay adımlarını inceleyin. ICANN belgeleri genel üst düzey alan adlarını kapsar; .tr ve her sağlayıcı için aynı talimat değildir.

Değişiklikten önce kayıtların tarihli dökümünü alın; sonrasında siteyi ve e-postayı ayrı ayrı doğrulayın. Sağlayıcı hesabına erişemiyorsanız başka birinin girişini denemeyin; kayıt şirketinin resmî destek ve kimlik doğrulama yolunu kullanın.

İşletme sahipliğini günlük teknik yetkiden ayırın

İşletmenin ana hesabı faturalama ve kurtarmayı; ajans kullanıcıları içerik, güncelleme veya bakım gibi görevleri üstlenebilir. Ortak kullanıcı adı yerine her kişiye ayrı erişim verin. Çalışan ayrıldığında erişimi tek başına kaldırabilirsiniz.

“Tam erişim” her görev için gerekli değildir. Editör içerik güncelleyebilir; teknik yönetici yayın ayarlarını, işletme sahibi kullanıcı ve faturalamayı yönetebilir. Rol adlarını her sağlayıcıda ayrıca doğrulayın. Geniş yetki gerekiyorsa nedenini, süresini ve onaylayan kişiyi kaydedin.

Yeni sorumlu kendi hesabıyla giriş yapmalı ve kurtarma yöntemini sınamalıdır; işletmeden ikinci bir yetkili de yedek olabilir. Yazılım proje devri rehberi kod ve işletim bilgisini, bu yazı ise hesap kontrolü ve erişim devrini ele alır.

Kurtarma ve giriş güvenliğini devir testine katın

Giriş yapmak hesabı kurtarabilmek demek değildir. Kurtarma e-postası eski çalışanda, doğrulama telefonu kişisel hatta veya yenileme kartı tek kişideyse erişim kaybı riski oluşur. Şirketin kontrol ettiği kurtarma adresini ve yedek sorumluyu belirleyin; posta kutusuna erişimi de sınayın.

Çok adımlı doğrulama yalnız parola kullanımına göre ek kontrol sağlar; seçeneklerin koruması farklıdır. CISA, kuruluşlara bu doğrulamayı kullanmalarını ve kimlik avına dayanıklı yöntemleri önceliklendirmelerini önerir. Sağlayıcının sunduğu seçeneği ve cihaz kaybında kurtarmayı birlikte planlayın; kodları ortak mesajlaşmada paylaşmayın.

CMS, yedek ve ölçüm hesaplarını ayrı doğrulayın

İşletme editörü kendi hesabıyla taslak ve önizlemeyi deneyebilmelidir. Teknik ekip yayın, sunucu veya kod işini sürdürüyorsa sürüm ve destek sorumlusu da bilinmelidir. CMS seçimini gerçek görevlerle deneme rehberi, içerik kullanımını ayrıntılandırır.

Yedeği görebilmek ile geri yükleyebilmek aynı değildir. Nerede tutulduğunu, kimlerin geri yükleyebileceğini ve son güvenli denemenin sonucunu kaydedin; üretim sitesinde rastgele deneme yapmayın. Yedekleme ve geri yükleme rehberi, dosyanın varlığından çok çalışır geri dönüşü sınar.

Ölçüm hesabında işletme raporları görebiliyor mu, yetkili kim ve doğrulama hangi e-postaya bağlı? Sağlayıcı ekranları değişebildiğinden eski adımları kopyalamayın. Site adresleri de değişecekse eski adresleri koruyarak yenileme rehberine bakın; bu yazı hesap sahipliğine odaklanır.

Erişim kaybı için yedek sorumlu belirleyin

İşletmedeki tek yetkili tatile çıktığında, işten ayrıldığında veya cihazını kaybettiğinde alan adı yenilemesi ve kurtarma süreci durmamalıdır. Her kritik hizmet için en az bir yedek sorumlu belirleyin; bu kişiye gereksiz geniş yönetici yetkisi vermek yerine kurtarma ve acil durum rolünü sağlayıcının sunduğu yöntemlerle tanımlayın. Yedek kişinin kurumsal posta kutusuna ve gerekli güvenli kasaya ulaşabildiğini, acil durumda kimin onay vereceğini önceden netleştirin.

Yedek sorumlu belirlemek ortak parola paylaşımı anlamına gelmez. Kişiye ayrı kullanıcı açılabiliyorsa ayrı hesap kullanın ve rolü sınırlandırın. Sağlayıcı tek kullanıcı destekliyorsa, erişim kasasının işletme tarafından yönetildiğini ve kurtarma yönteminin bir kişiye bağlı kalmadığını doğrulayın. Bu düzeni ekip değişiminden sonra değil, normal çalışma döneminde kontrol etmek daha güvenlidir. Tatbikat için gerçek kurtarma kodlarını kullanmayın; sağlayıcının güvenli test veya destek yolunu önceden öğrenin.

Envanterin güncel olup olmadığını birkaç ayda bir veya sorumlu, sağlayıcı ya da faturalama değiştiğinde gözden geçirin. Eski kişilerin listede kalması kadar, artık kullanılmayan bir hizmete ait kurtarma adresinin boşta kalması da sorun yaratabilir. Değişiklik günlüğünde kim, hangi hesabı, ne zaman ve hangi onayla güncelledi bilgisini tutun; gizli kodları veya parolaları günlüğe eklemeyin.

Devir sırasını canlı siteyi koruyacak şekilde kurun

Yeni sorumlu önce işletme hesabına eklenir, görev yetkisi doğrulanır ve kayıt güncellenir. Yedek, alan adı, DNS ve CMS sorumluları ayrı test edildikten; kurtarma yöntemi ve açık işler teyit edildikten sonra eski ekip erişimi kaldırılır. Böylece acele parola değişimi hizmeti kesintiye uğratmaz.

DNS veya sunucu değişimini ayrı planlayın: değişecek kayıt, onaylayan kişi, etkilenecek hizmet ve geri dönüş değeri. Önce-sonra kontrolünü kaydedin. Bütün hesapları aynı gün taşımak gerekmez; sıra işletme sorumlusu ve sağlayıcıyla belirlenmelidir.

Teslim kanıtını kısa bir çalışma oturumuyla tamamlayın

“Erişim verildi” sözünü somut bir oturumla doğrulayın: işletme sorumlusu kendi cihazından hesaba girsin ve rolü kontrol etsin. Parola veya tek kullanımlık kodu mesajlaşmaya yazmayın. Taslak önizleme ya da yedek envanteri gibi zararsız kontrol seçin; gerçek DNS veya yayın değişikliğini onaylı bakım zamanında yapın.

Devir notunda hizmet, işletme sorumlusu, ajans görevi, kurtarma yolu, açık işlem, tarih ve sonuç bulunsun. Başarısız denemeyi de kaydedin. Yazılım devri ve site geçişi teknik konuları tamamlar; erişimleri işletme düzenli gözden geçirmelidir.

Sık Sorulan Sorular

Web sitesi ajans hesabında kalabilir mi?

Ajansın kendi çalışma hesabıyla siteyi yönetmesi mümkündür; fakat işletmenin hiçbir sahiplik, faturalama veya kurtarma erişimi olmaması ciddi bir operasyon bağımlılığı yaratır. Önce hizmetin kayıt sahibi, yönetici ve kullanıcı rollerini ayırın. İşletme adına hangi hesabın kullanılacağını ve ajansa hangi görev için erişim verileceğini sözleşme ve teslim notunda açıkça belirleyin.

Alan adını yeni ajansa taşımak zorunlu mudur?

Her zaman değil. Alan adı kayıt şirketini değiştirmek, DNS kayıtlarını güncellemek ve siteyi başka barındırmaya taşımak farklı işlemlerdir. Gereksinimi yalnız ajans değişti diye varsaymayın. Önce kimin kayıt sahibi olduğunu, mevcut DNS ve e-posta hizmetlerini, yenileme tarihini ve teknik sorumluyu doğrulayın; sağlayıcı değişikliği gerekiyorsa buna özel bir geçiş planı hazırlayın.

Alan adı sahibi bilgisi değiştirilirken neye dikkat edilmeli?

Uygulama alan adı uzantısına ve kayıt şirketine göre değişebilir. Bazı genel üst düzey alan adlarında kayıt sahibi bilgilerindeki değişiklik, başka kayıt şirketine aktarımı geçici olarak sınırlayan bir kilit doğurabilir. İşletme sahibi veya yetkilisi, değişiklikten önce ilgili uzantı ve sağlayıcının güncel kuralını doğrudan kontrol etmeli; bu bilgiyi .tr dahil bütün uzantılar için aynı kabul etmemelidir.

Ajansa ana yönetici hesabının parolasını vermeli miyiz?

Günlük iş için paylaşılan ana parola yerine mümkün olduğunda kişiye özel kullanıcı hesabı ve görevle sınırlı rol verin. Böylece kimlerin eriştiği izlenebilir ve ekip değiştiğinde tek bir ortak hesabı herkesten geri almak gerekmez. Sağlayıcı ayrı kullanıcı desteklemiyorsa, geçici erişim yöntemini, güvenli saklama aracını ve iş bitince parolanın yenileneceği zamanı işletme sorumlusu belirlemelidir.

Eski ajans erişimini ne zaman kaldırmak gerekir?

Yeni işletme sorumlusu kendi hesabıyla giriş yapabildiğini, kurtarma kanalını kontrol ettiğini, gerekli yedek ve yayın kayıtlarına ulaşabildiğini doğruladıktan sonra. Açık bir destek veya bakım görevi eski ekibe bağlıysa onu da devir listesine alın; erişimi belirsiz süreyle açık bırakmak yerine bitiş zamanını ve son sorumlusunu kaydedin. Parola değişimi veya kullanıcı silme işlemi öncesinde hizmet kesintisi riskini değerlendirin.

DNS ayarlarını yeni ekibe gönderirken neleri paylaşmalıyız?

Yetkisiz kişilere tüm hesap parolasını göndermek yerine, değişecek kayıtların envanterini ve onay akışını paylaşın. İşletme, mevcut ad sunucularını, web ve e-posta için kullanılan kayıtları, değişiklik zamanını ve geri dönüş değerlerini sağlayıcıyla doğrulamalıdır. Bu liste parola veya kurtarma kodu içermez; DNS değişikliği yetkisi, ilgili görev için ayrı ve izlenebilir biçimde verilmelidir.

CMS erişimi site teslimi için yeterli midir?

Yalnız içerik güncellemesi için yeterli olabilir; ancak sitenin çalışması barındırma, alan adı, yedek, kod deposu veya başka hizmetlere bağlıysa bütün işletim zinciri ayrıca ele alınmalıdır. Kimin içerik yayımladığı ile kimin sunucu, DNS veya geri yükleme işlemi yaptığı farklı olabilir. Teslim notunda bu sınırları ve gerektiğinde aranacak teknik sorumluyu gösterin.

Bir alan adı devrinin tamamlandığını nasıl anlarız?

Tek bir parola veya ekran görüntüsü yerine, doğru kayıt sahibinin ve işletme sorumlusunun doğrulanması, yenileme/fatura bilgisinin erişilebilir olması, DNS sorumlusu ile değişiklik sürecinin bilinmesi ve kurtarma kanalının işletme tarafından kontrol edilmesi birlikte değerlendirilmelidir. Başka kayıt şirketine aktarım planlandıysa, sağlayıcının gönderdiği resmî onayların sonuçlanması gerekir. Web sitesi ve e-posta çalışması da ayrı ayrı doğrulanmalıdır.