2018 yılında yürürlüğe giren Avrupa Birliği Genel Veri Koruma Tüzüğü (GDPR), kişisel verilerin toplanması, işlenmesi ve paylaşılması konusunda ciddi kısıtlamalar getirdi. Bu düzenleme yalnızca AB içindeki bireyleri değil, onların verilerini işleyen dünya genelindeki tüm şirketleri kapsar. Alan adı kayıt sistemleri de doğrudan kişisel veriler içerdiğinden, GDPR bu alanı da etkiledi. Özellikle WHOIS sistemlerinde yer alan kişisel bilgiler olan ad, adres, telefon numarası gibi GDPR ile birlikte artık açık şekilde yayınlanamaz hale geldi. Dilerseniz bir domainin WHOIS sorgulamasını yaparsanız “REDACTED” olarak gözükecektir.
Temporary Specification nedir?
ICANN’in Kayıt Kuruluşu Akreditasyon Anlaşması (Registrar Accreditation Agreement – RAA) ile GDPR arasındaki çatışma noktalarını çözmeyi amaçlayan çok sayıda kayıt kuruluşu gereksiniminin getirilmesini içeriyordu.
GDPR’ın yürürlüğe girmesiyle birlikte ICANN, Avrupa yasalarına uyum sağlamak amacıyla 2018’de “Temporary Specification for gTLD Registration Data” adlı bir düzenleme yayınladı. Bu geçici belge, ICANN sözleşmeleri kapsamında faaliyet gösteren kayıt operatörlerinin (registrar) ve kayıt otoritelerinin (registry) hangi verileri toplayıp hangilerini yayınlayabileceğini geçici olarak belirledi. Bu spesifikasyona göre, kayıt esnasında contact object alanlarının (registrant, admin, tech, billing) zorunlu tutulması artık hem yasal açıdan riskli hem de teknik olarak gereksiz hale geldi.
Bu politikayı özel kılan nedir?
Bu politikayı benzersiz kılan şeyin ne olduğunu anlamak için, ICANN politikasının tipik olarak nasıl geliştirildiğini anlamak gerekiyor. Normalde, sözleşmeli taraflar (kayıt memurları – registrar ve kayıt defterleri – registry) için bağlayıcı olan herhangi bir politika, “politika geliştirme süreci” (veya “PDP”) adı verilen tanımlanmış bir yol boyunca tüm paydaşlardan katkı alınarak aşağıdan yukarıya, katılımcı bir süreçle geliştirilir.
Sonra kamuoyunun yorumuna sunulur, rafine edilir ve ardından oylama için ICANN’in Genel Adları Destekleme Örgütü (Generic Names Supporting Organization – GNSO) Konseyine sunulur. Konsey tarafından onay alırsa, nihai inceleme ve onay için ICANN Yönetim Kuruluna sunulur. Ancak ICANN Yönetim Kurulu politikayı onayladıktan sonra, yukarıdaki RAA’daki sözleşmesel bir hüküm aracılığıyla kayıt memurları ve kayıt defterleri için bağlayıcı hale gelir.
Bu şartname bir “acil durum politikası” olarak yayınlanmıştır, yani ICANN Yönetim Kurulu’nun büyük çoğunluğu tarafından kabul edilmiş ve normal politika geliştirme sürecini atlamıştır. Acil durum politikaları, ICANN Yönetim Kurulu tarafından her doksan (90) günde bir yeniden onaylanmalıdır ve bir yıldan fazla süre var olamaz. Buradaki fikir, bir yılın ICANN topluluğunun normal, aşağıdan yukarıya geliştirme yolunda kalıcı bir politika geliştirmesi için yeterli zaman sağlamasıdır.
Bu politikanın kayıt kuruluşlarından talebi nedir?
Bu şartnamenin “uygulanması gereken” uzun bir madde listesi içerir ve bunların çoğu GDPR’ye dayanıyor.
Kayıt kuruluşları şunları yapmalıdır (must) veya yapacaktır (shall):
1. Kayıt kuruluşu kayıt sahibinin kişisel verileri için AB’de (EU) bulunan bir veriyi kullanıyorsa, genel WHOIS çıktısından kişisel olarak tanımlayıcı bilgileri sansürlemelidir. Sansürlenen alanlarda REDACTED FOR PRIVACY gibi bir ifade yazmalıdır. Bu sebeple sorguladığınız çoğu domainde contact kısmında bu ifadeyi görürsünüz çünkü sansürlüdür. Kayıt kuruluşunuzda bir domain kayıt ettiğinizde çoğu zaman domain gizliliğinin de aktif olduğunu görürsünüz. Bazen “Data Protected” ifadesi de görülür.
2. Üçüncü tarafların kayıt sahibine anonim olan bir e-posta veya web formu aracılığıyla ulaşmasını sağlayacak bir yöntem sağlanmalıdır. Bu sebeple WHOIS çıktılarında bazen URL görebiliyorsunuz. Sahibine ulaşmak da isteyebilirsiniz. Aşağıda “x.com” sorguladığımda buna dair bir örnek görebiliyorsunuz.
3. Kayıt sahibine yukarıda örnek gösterdiğim “Data Protected” ifadesi yerine iletişim bilgilerinin herkese açık WHOIS’de görüntülenmesine izin vermesini sağlayacak bir yol sağlanmalı. Bu genelde domain yönetimi panellerinde bulunuyor. Örneğin kendi alan adımın WHOIS gizliliğini kaldırdım ve böyle bir sonuç oluştu.
4. Kayıt sahiplerine, kayıt sahibinin kişisel verilerinin kimde olduğunu, nasıl işlendiğini, bir veri transferinin ne zaman ve neden uluslararası sınırları aştığını (geçerliyse) ve verilerin toplanmasının ve transfer edilmesinin belirli nedenlerini ve diğer konuları ayrıntılı olarak açıklayan zorunlu açıklamalar sağlanmalıdır (Bölüm 7.1). Bu kayıt kuruluşunuzun domain sözleşmelerinde veya KVKK sayfasında geçecektir
gTLD Temporary Specification’ın EPP etkisini teknik olarak inceleyelim.
Bir domain kayıt etmek istediğinizde veya güncellemek istediğinizde artık gTLD grubunda “contact” gönderilemeyecektir. Çünkü ana kayıt operatörü bunları kabul etmiyor. Aşağıda örnek olarak Identity Digital’in test ortamına bir isteği gösteriyorum.
Örnek EPP isteği:
<domain:create
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>recepseritdeneme.pro</domain:name>
<domain:period unit="y">2</domain:period>
<domain:ns>
<domain:hostObj>tr.apiname.com</domain:hostObj>
<domain:hostObj>eu.apiname.com</domain:hostObj>
</domain:ns>
<domain:registrant>CONTACT-12</domain:registrant>
<domain:contact type="admin">CONTACT-12</domain:contact>
<domain:contact type="tech">CONTACT-12</domain:contact>
<domain:authInfo>
<domain:pw>rE1mva#sAKFpp[xv</domain:pw>
</domain:authInfo>
</domain:create>EPP cevabı:
<result code="2306">
<msg>Parameter value policy error</msg>
<extValue>
<reason>Contact type not permitted: registrant</reason>
</extValue>
</result>Sadece “create” komutunda değil, XML içerisinde domain object altında contact bulunuyorsa yine kabul etmeyecektir.
Kabul edebilecek örnek XML örneği:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<create>
<domain:create
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd">
<domain:name>recepserit111.pro</domain:name>
<domain:period unit="y">1</domain:period>
<domain:ns>
<domain:hostObj>eu.recepserit.com</domain:hostObj>
<domain:hostObj>tr.recepserit.com</domain:hostObj>
</domain:ns>
<domain:authInfo>
<domain:pw>zC/7-d5HD3?ygN6</domain:pw>
</domain:authInfo>
</domain:create>
</create>
<clTRID>2ccda133-dca6-4f10-9fd4-d973de492129</clTRID>
</command>
</epp>Bilindiği üzere Verisign yıllardır “contact” kabul etmiyor çünkü kendisi bu verileri depolamıyor. Bu sebeple kendilerine gönderdiğimiz formatla diğer operatörlere istek yapılmalıdır.
Her kayıt kuruluşu bu politikalara uymakla yükümlüdür. Mutlaka önümüzdeki günlerde daha farklı politikaları inceleyeceğiz.
Yorum bırakın