Üçüncü Parti Uygulama Geliştiricisi

Amazon appstore üzerinde herkese açık uygulama geliştirmek istiyorsanız, bu yöntem ile ilerleyebilirsiniz.

Kayıt Genel Bakış

Amazon Satış Ortağı API ile kamu geliştirici kaydı, talep ettiğiniz rollere bağlı olarak iki ana inceleme aşaması içerir:

Herkese Açık Entegrasyon Kaydını Oluşturma

1. Solution Provider Portal sayfasına giriş yapın.
2. Menüye ilk defa giriş yapıyorsanız Herkese açık geliştirici için kayıt olmak için devam edin. Daha önceden geliştirici profili oluşturduysanız Profili Görüntüle linkine tıklayın.
3. DRAF'ı doldurun.
   1. Amazon Kullanım Şartları Politikası ve Veri Koruma Politikası bölümlerini inceleyin.
   2. Veri Erişimi bölümünde_Herkese açık geliştirici: Diğer şirketlerin kullanabileceği herkese açık uygulamalar geliştirip sunuyorum._ seçeneğini işaretleyin.
   3. Uygulamanızın desteklediği pazaryerlerini seçin.
4. Seçtiğiniz rollere göre (eğer kısıtlı rolleri seçtiyseniz) DRAF başvurunuz onaylandıktan sonra SA Değerlendirmesi (Güvenlik Değerlendirmesi) başlar. Değerlendirmeyi yapan ekip size inceleme süreci hakkında bilgi verecektir.

Amazon DARF'da Neleri İnceler

Web Sitesi Değerlendirmesi

• Herkese açık olmalıdır (giriş duvarları, yapım sayfaları veya güvenlik uyarıları olmamalıdır)
• Hizmetlerinizi ve Amazon satıcılarına nasıl fayda sağladığınızı açıkça tanımlamalıdır
• HTTPS güvenlik protokolünü uygulamalıdır
• Kapsamlı gizlilik politikası ve hizmet şartlarını görüntülemelidir

Geliştirici Profil Doğrulaması

• Doğru iş ve iletişim detayları
• Uygulamanızın amacı ve işlevinin net açıklaması
• SP-API'nin kullanım amacı hakkında detaylı bilgi
• Gerekli API bölümleri ve rollerinin belirtilmesi
• Amazon'un veri koruma gerekliliklerini anlama gösterimi

Politika Uyumu

• Kabul Edilebilir Kullanım Politikasına uyum
• Veri Koruma Politikasına uyum
• Çözüm Sağlayıcı Anlaşması kabulü
• Detaylı kullanım senaryosu dokümantasyonu

Yaygın DARF Sorunları ve Bunlardan Nasıl Kaçınılır

• Web sitesine erişilemiyor: Sitenizin canlı olduğundan, parola korumalı olmadığından ve güvenlik uyarıları olmadığından emin olun
• Eksik iş bilgisi: Tam şirket detayları ve doğru iletişim bilgileri sağlayın
• Belirsiz kullanım senaryosu açıklamaları: API'yi nasıl kullanacağınız ve satıcılara ne değer sağladığınız konusunda spesifik olun
• Eksik gizlilik politikası veya şartlar: Bunlar tam, erişilebilir ve düzenlemelere uygun olmalıdır
• Belirsiz rol gereksinimleri: Rolleri seçmeden önce rol eşleme dokümantasyonunu kapsamlı şekilde inceleyin

Roller ve Açıklamaları

SP-API'da farklı veri türlerine erişim için belirli roller (roles) bulunmaktadır. Her rol, belirli API işlemlerine erişim sağlar.

Restricted Roles (Kısıtlı Roller) – Kişisel Veri İçerir

Direct to Consumer Shipping (Tüketiciye Doğrudan Gönderim): Bu rol, MFN siparişleri için kargo etiketleri oluşturmanıza ve teslimat süreçlerini yönetmenize olanak tanır.
Kullanım Alanları:

• Kargo etiketlerinin otomatik oluşturulması
• Easy Ship programı entegrasyonu
• MFN siparişleri için kargo süreçlerinin yönetimi
• Müşteri teslimat bilgilerine erişim

Tax Invoicing (Vergi Faturalama): Bu rol, sipariş faturalarını oluşturmanıza, faturaları yüklemenize ve vergi raporlarına erişmenize olanak tanır.
Kullanım Alanları:

• E-fatura oluşturulması
• AFN ve MFN siparişleri için faturalama
• Türk mevzuatına uygun fatura süreçlerinin yönetimi

Unrestricted Roles (Kısıtlı Olmayan Roller) – Kişisel Veri İçermez:

Bu roller kişisel veri içermediği için daha kolay onay alınır. Örnek roller:

• Products (Ürünler)
• Inventory (Envanter)

Entegrasyon kaydında sizden istenilen bilgileri incelemek için tıklayın

 

Güvenlik Değerlendirmesi (SA) - Yalnızca Kısıtlı Roller İçin

Kısıtlı roller şunlara erişim sağlayanları içerir:
• Müşteri adları ve adresleri
• Alıcı iletişim bilgileri
• Sipariş düzeyinde kişisel olarak tanımlanabilir veriler

SA Değerlendirme Süreci

Değerlendirme üç aşamadan oluşur: anket sunumu, Amazon güvenlik ekibiyle değerlendirme görüşmesi ve tespit edilen eksikliklerin giderilmesi.

Temel Değerlendirme Alanları

Herkese Açık Geliştiriciler İçin Gerekli Güvenlik Kontrolleri

Kısıtlı roller talep eden herkese açık geliştiricilerin, tüm alanlarda kapsamlı güvenlik kontrollerinin uygulandığını göstermeleri gerekmektedir. Aşağıda temel güvenlik gereksinimleri yer almaktadır:

Veri Şifreleme

• Depolama sırasında şifreleme: Tüm kişisel veriler, sektör standardı algoritmalar (AES-256 veya eşdeğeri) kullanılarak şifrelenmelidir.
• İletim sırasında şifreleme: TLS 1.2 veya üzeri, SFTP ya da SSH-2 gibi güvenli protokoller kullanılmalı; güvenilir olmayan/çok kiracılı (multi-tenant) ortamlardan geçişte uçtan uca şifreleme sağlanmalıdır.
• Anahtar yönetimi: Güvenli anahtar depolama ve döndürme prosedürleri uygulanmalıdır.
• Sertifika yönetimi: Uygun yenileme süreçlerine sahip geçerli SSL/TLS sertifikaları kullanılmalıdır.
• Programatik kimlik bilgileri (API anahtarları) bekleme halinde şifrelenmeli, yalnızca yetkili personel/servislerce erişilebilir olmalı ve en az 12 ayda bir veya güvenlik ihlali şüphesinde rotate edilmelidir.

Erişim Kontrolü

• Çok faktörlü kimlik doğrulama (MFA), PII erişimiyle sınırlı olmaksızın tüm kullanıcı hesapları için zorunludur.
• Ayrıcalık ilkesine dayalı rol tabanlı erişim kontrolü (RBAC)
• Düzenli erişim incelemeleri ve hızlı yetkilendirme kaldırma prosedürleri
• Belgelenmiş erişim isteği ve onay iş akışları
• Güçlü parola politikaları ve kimlik bilgisi yönetimi
• En fazla 10 ardışık başarısız giriş denemesinden sonra hesap kilitleme kontrolü uygulanmalıdır.
• Onaylı Kullanıcılar (belgelenmiş iş ihtiyacı olan ve gerekli eğitimleri tamamlamış personel) için en az yılda bir kez veri koruma ve BT güvenliği farkındalık eğitimi zorunludur.

Ağ Güvenliği

• Belgelenmiş kural setleriyle güvenlik duvarı uygulaması
• Üretim ve geliştirme ortamlarını ayıran ağ segmentasyonu
• Saldırı tespit/önleme sistemleri (IDS/IPS)
• VPN veya güvenli uzaktan erişim çözümleri
• Düzenli ağ güvenlik açığı taramaları
• Protokol fark etmeksizin (HTTP/S, gRPC, GraphQL, WebSocket vb.) tüm herkese açık/internete dönük uç noktalar için Web Application Firewall (WAF) veya eşdeğeri uygulama katmanı koruması zorunludur.
• Anti-virüs, anti-malware, Endpoint Detection and Response (EDR) veya bulut-native eşdeğer korumalar; destekleniyorsa otomatik güncelleme, desteklenmiyorsa en az ayda bir manuel güncelleme yapılmalıdır.
• Çalışanların uç nokta koruma yazılımlarını (anti-virüs, EDR vb.) devre dışı bırakmasını, kaldırmasını veya değiştirmesini engelleyen kontroller uygulanmalıdır.
• Bilgiye erişen tüm cihazlarda depolama şifrelemesi, çıkarılabilir medya kısıtlamaları, kontrollü yönetici erişimi ve en fazla 15 dakika hareketsizlik sonrası otomatik ekran kilidi bulunmalıdır.
• Kişisel veya yönetilmeyen cihazlardan erişim, MDM/UEM gibi uç nokta güvenlik kontrolleriyle yönetilmediği sürece kısıtlanmalıdır.
• Ağ mimarisi diyagramları ile güvenlik kontrollerinin (firewall, WAF, IDS/IPS, uç nokta koruması) uygulandığına dair kanıt belgeleri saklanmalıdır.

Güvenlik Açığı Yönetimi

• Düzenli güvenlik açığı taraması. Kritik güvenlik açıkları tespitten itibaren 7 gün, yüksek riskli açıklar 30 gün içinde giderilmelidir
• Tanımlanmış SLA'lara sahip belgelenmiş yama yönetimi süreci
• Kritik güvenlik açıklarının giderilmesi (sıklık detaylarıyla birlikte)
• Sızma testi, endüstri standardı bir metodoloji kullanılarak en az 365 günde bir yapılmalı; ağ altyapısı, bulut ortamları, uygulama katmanı varlıkları (web uygulamaları, API'ler, veritabanları) ve varsa masaüstü/mobil uygulamalar kapsanmalıdır.
• Varlık envanteri ve yapılandırma yönetimi çeyreklik olarak güncellenmelidir.
• Güvenlik açığı taraması en az 30 günde bir yapılmalıdır.
• Önemli ağ, uygulama veya altyapı değişikliklerinden sonra ek (değişiklik tetiklemeli) güvenlik açığı taraması yapılmalıdır.
• Felaket kurtarma: coğrafi olarak ayrılmış ikincil/yedek site ile RTO/RPO hedeflerine uygun zamanında kurtarma sağlanmalıdır.

Uygulama Güvenliği

• Güvenli yazılım geliştirme yaşam döngüsü (SDLC), kod inceleme süreçleri ve güvenlik testi.
• Statik ve dinamik uygulama güvenlik testi (SAST/DAST).
• Girdi doğrulama ve çıktı kodlama, API güvenlik kontrolleri ve hız sınırlama (rate limiting).
• Hassas kimlik bilgileri (şifreleme anahtarları, gizli erişim anahtarları, şifreler) kaynak kodda asla sabit kodlanmamalı ve herkese açık kod depolarında (public repo) yer almamalıdır.
• Test ve üretim ortamları birbirinden ayrı tutulmalıdır.

Kayıt ve İzleme

• Servis API'leri, depolama katmanı API'leri ve yönetim panelleri dahil tüm kanallarda; başarı/başarısızlık durumu, tarih/saat, erişim denemeleri, veri değişiklikleri ve sistem hataları kaydedilmelidir.
• Loglar gerçek zamanlı (örn. SIEM aracıyla) ya da en az iki haftada bir incelenmelidir.
• Loglara erişim kontrolleri uygulanmalı ve loglar yaşam döngüleri boyunca yetkisiz erişim/kurcalamaya karşı korunmalıdır.
• Loglar, yasal zorunluluk (vergi/regülasyon) olmadıkça PII içermemelidir.
• Loglar bir güvenlik olayı durumunda referans olması için en az 12 ay saklanmalıdır.
• Çoklu yetkisiz çağrılar, beklenmeyen istek oranları/veri çekme hacimleri ve canary veri kayıtlarına erişim gibi şüpheli işlemler için araştırma alarmları kurulmalıdır.
• Bilginin korunan sınırların dışına çıkarılıp çıkarılmadığını (örn. Dark Web'de) tespit eden izleme alarmları ve süreçleri uygulanmalıdır.

Olay Müdahalesi

• Belgelenmiş bir olay müdahale planı ve/veya runbook; roller, sorumluluklar, olay türleri, müdahale prosedürleri ve Amazon'a bildirim/eskalasyon yollarını tanımlamalıdır.
• Plan, en az 6 ayda bir VE sistem, kontrol, operasyonel ortam, risk seviyesi veya tedarik zincirinde yaşanan her önemli değişiklikten sonra gözden geçirilmelidir.
• Bir güvenlik olayı tespit edildiğinde Amazon'a ([email protected]) 24 saat içinde bildirim yapılmalıdır.
• Olay Yönetimi İrtibat Kişisi (IMPOC) belirlenmeli ve iletişim bilgileri güncel tutulmalıdır.
• Her olay araştırılmalı; açıklama, düzeltici faaliyetler ve tekrarı önlemeye yönelik kontroller belgelenmeli; kanıt/kayıtların gözetim zinciri (chain of custody) korunmalıdır.
• Risk değerlendirme ve yönetim süreci, üst yönetim tarafından en az yılda bir kez gözden geçirilmelidir.

Veri Saklama ve İmha

• Bilgiler yalnızca toplanma amacına hizmet ettiği veya yasal/vergisel yükümlülükler için gerekli olduğu sürece saklanmalı; yetkilendirilmiş kullanım kapsamının dışında tutulmamalıdır.
• Amazon'un silme talebinden itibaren veya yetkilendirmenin iptali, erişimin sona ermesi ya da hizmetin sonlanması gibi tetikleyici olaylardan itibaren en geç 30 gün içinde kalıcı ve güvenli silme yapılmalıdır.
• Güvenli silme, NIST 800-88 gibi endüstri standardı imha (sanitization) süreçlerine uygun şekilde gerçekleştirilmelidir.
• Amazon talep ettiğinde, verilerin güvenli şekilde imha edildiğine dair yazılı sertifikasyon sağlanmalıdır.
• PII, sipariş teslimatından sonra en fazla 30 gün saklanabilir; yasal zorunluluk halinde bu süre yalnızca ilgili yasaya uyum amacıyla uzatılabilir.
• Test edilmiş kurtarma prosedürleriyle düzenli veri yedekleme ve coğrafi olarak ayrı yedekleme konumu sağlanmalıdır.
• Yedekler şifrelenmeli (en az AES-128/RSA-2048) ve güvenli şekilde depolanmalıdır.
• Medya imha ve varlık yok etme prosedürleri uygulanmalıdır.
• Veri Atıfı: PII içeren (veya PII ile birlikte bulunan) her veritabanında, verinin kökenini ayrıştırmak için ayrı bir veritabanı kullanılmalı veya verinin kaynağını etiketleyip tanımlayan bir mekanizma uygulanmalıdır.

Üçüncü Taraf Risk Yönetimi

• Satıcı güvenlik değerlendirme süreci
• PII erişimi olan tüm satıcılar için durum tespiti dokümantasyonu
• Üçüncü taraflarla veri işleme anlaşmaları
• Düzenli satıcı güvenlik incelemeleri
• Belgelenmiş veri paylaşım mekanizmaları ve kontrolleri
• Amazon verisine erişimi olacak satıcı veya alt yüklenicilere erişim verilmeden önce, en az yılda bir kez düzenli üçüncü taraf risk değerlendirmesi yapılmalıdır.

Uyumluluk ve Eğitim

• Tüm çalışanlar için düzenli güvenlik farkındalığı eğitimi ve gizlilik/veri koruma eğitimi verilmelidir.
• PII işleyen çalışanların iş sözleşmelerinde PII'nin gizliliğini koruma yükümlülüğüne ilişkin maddeler yer almalıdır.
• Tüm PII için hangi veri alanlarının nasıl toplandığı, işlendiği, saklandığı, kullanıldığı, paylaşıldığı ve imha edildiğine dair bir veri işleme faaliyetleri kaydı tutulmalıdır.
• Veri sahiplerinin erişim, düzeltme, silme veya paylaşımı/işlenmeyi durdurma haklarını destekleyen teknik ve organizasyonel süreç ve sistemler uygulanmalıdır.
• GDPR, CCPA ve diğer geçerli düzenlemelere uyum sağlanmalı, güvenlik politikaları düzenli olarak gözden geçirilip güncellenmelidir.
• Uyum kayıtları, sözleşme süresi boyunca ve sonrasında en az 12 ay saklanmalı; Amazon'un yazılı talebi üzerine uyum sertifikasyonu sağlanmalıdır.

Yapay Zeka Ajanları (Agent) Kullanımı

Portal Sözleşmesi'ne eklenen yeni 1.3 numaralı madde uyarınca, Amazon hizmetlerine erişmek veya bu hizmetlerle etkileşime girmek için bir otomasyon/AI “Agent” konuşlandıran, etkinleştiren veya yetkilendiren geliştiriciler için ayrı kurallar getirilmiştir:

• Tüm Agent'lar kendilerini otomatik sistem olarak açıkça tanımlamalı ve Amazon Hizmetlerine erişirken ilgili Agent Policy'de belirtilen teknik uyumluluk standartlarına her zaman uymalıdır.
• Amazon'un erişimin durdurulmasını açıkça talep ettiği durumlarda Agent'ların Amazon Hizmetlerine erişmesi yasaktır.
• Amazon, teknik veya başka önlemlerle Agent erişimini kendi takdirine bağlı olarak sınırlama/kısıtlama hakkını saklı tutar.
• Başvurunuzda API'ye erişim için otomasyon/AI ajanı kullanıp kullanmadığınızı belirtmeniz ve ilgili Agent Policy'ye uyum sağladığınızı teyit etmeniz istenebilir.

👍

Geliştirici başvurunuz onaylandıktan sonra Uygulama Yayınlama bölümüyle devam edebilirsiniz.

Dikkat Edilmesi Gerekenler

❗️

Amazon yetki alabilmeniz için politikalara uymanız gereklidir. Politikaları incelemek için geliştirici profili bölümündeki Amazon Kullanım Şartları Politikası ve Veri Koruma Politikası bölümlerini inceleyin.

📘

Yetki veren herhangi bir satıcı uygulamayı kullanabilir.

📘

Yayınlanan uygulamalarda sınırsız sayıda satıcı yetki verebilir. Taslak durumundaki uygulamaya yalnızca 25 firma yetki verebilir.

📘

Uygulamanızın desteklediği Marketplace sayısını arttırmanız durumunda, onay sürecine düşmez.

Geliştirici kaydı onaylandıktan sonra, SP-API servislerine erişebilmek için için uygulama kaydı oluşturmanız gereklidir. Uygulamanızı appstore üzerinde yayınlayabilir veya özel uygulama olarak yaratabilirsiniz.

Uygulama Oluşturma

1. Geliştirici profili sayfasında Yeni uygulama istemcisi ekle'ye tıklayın. Uygulama adını yazın ve API Türünde SP-API olarak seçin.
2. Desteklenen ticari işletmeleri seçin.
3. Rollerinizi seçin. 3 adet rolde kişisel verileri içerir. Kişisel veriler kısıtlanmış rol olarak adlandırılır. Kısıtlanmış roller için aşağıdaki bilgilendirmelere göre gerekli rollere karar verin.

   1. 🚧

      Doğrudan Tüketiciye Kargo - Sipariş bilgilerinde, kargolanacak adres bilgilerine erişmek ve kargo barkodlarını almak için bu rolü işaretleyin.

      Doğrudan tüketiciye kargo rol yetkisinin erişeceği verileri detaylı incelemek için tıklayın.

   2. 🚧

      Vergi Faturalandırması - Sipariş bilgilerinde bireysel ve kurumsal fatura bilgilerine erişmek ve FBA siparişlerini çekebilmek için bu rolü işaretleyin.

      Veri faturalandırması rol yetkisinin erişeceği verileri detaylı incelemek için tıklayın.

   3. 🚧

       Vergi Ödemesi - Bu rol Türkiye'de aktif değildir. Yurtdışı pazaryerlerine bağlanıyorsanız bu rolü talep edebilirsiniz.

      Vergi ödemesi rol yetkisinin erişeceği verileri detaylı incelemek için tıklayın.

4. Uygulamanızı OAuth yöntemiyle giriş yaptırıcaksanız OAuth Oturum Açma URI ve OAuth Yönlendirme URI bölümlerini doldurun.
   1. OAuth Oturum Açma URI : OAuth Oturum Açma URI, uygulamanızın web sitesinin giriş sayfasına yönelik URI'dir.
   2. OAuth Yönlendirme URI : Amazon, yetkilendirme bilgileriyle beraber satış ortağını tarayıcı üzerinden uygulamanıza yönlendirmek için bu URI'yi kullanır.
      1. OAuth URI yetki alma bölümünde appstore ve websitesi yetkilendirmesi bölümlerinde kullanılır.
      2. Bu bölümde test, canlı için birden fazla link ekleyebilirsiniz. (Localhost linkleri desteklenmemektedir.)
5. Uygulamanızı yarattıktan sonra Yetki Alma bölümüne geçin.

 Uygulama ve Yetki Bilgilerinin Görüntülenmesi

1. Uygulama satırınızdaki LWA kimlik bilgileri görüntüle seçeneğine tıklayın.
2. İstemci tanımlayıcısı ve İstemci sırrı uygulama yetki bilgilerini içerir.
3. Yetki alma süreçlerinde kullanmak üzere bu bilgileri saklayın.

Uygulama Yetkilerinin Yenilenmesi

1. Yenilemeniz gereken istemci uyarı olarak satırda görünür. Uygulama satırınızdaki LWA kimlik bilgileri bölümüne girin ve yenile butonuna tıklayarak yenileyin.

Dikkat Edilmesi Gerekenler

❗️

Uygulamaya ait istemci bilgileri Amazon kurallarına göre belirli dönemlerde yenilemeniz gerekmektedir. Uygulamanız için istemci bilgilerini yenilemeniz gerekirse e-posta ile iletilecektir.

Önemli Notlar

📘

Uygulamalara erişim sağlanması için uygulamanın yayınlanmasına gerek bulunmamaktadır.

📘

 Yayınlama isteği gönderilen uygulamaların değerlendirilmesi ortalama 14 gün sürer. Kişisel verileri talep ettiğiniz özel roller mevcut ise değerlendirme süresi artar.

Entegrasyon Kaydında Sizden İstenilen Bilgiler

İş aktivitenizi ve SP-API kullanım amacınızı açıklayın
Ne Beklenir:

• API'yı hangi süreçler için kullanacağınız (sipariş yönetimi, faturalama, kargolama)
• Manuel süreçlerin nasıl otomatikleştirileceği
• Hangi sistemlerle entegrasyon yapılacağı (ERP, fatura sistemi, kargo şirketleri)
• API erişimi için bir otomasyon/AI ajanı (Agent) kullanılıp kullanılmadığı; kullanılıyorsa Agent Policy'ye uyum beyanı

Politika Referansı: Acceptable Use Policy - Veriler yalnızca belirtilen amaçlar için kullanılmalıdır

PII (Kişisel Olarak Tanımlanabilir Bilgiler) kullanma gerekçenizi açıklayın
Ne Beklenir:

• Hangi roller için PII'ya ihtiyaç duyduğunuz (Direct to Consumer Shipping, Tax Invoicing)
• PII verilerini hangi süreçlerde kullanacağınız
• Yasal zorunlulukları belirtin (7318 sayılı Kanun - e-fatura zorunluluğu). PII'nin sipariş teslimatından itibaren en fazla 30 gün saklanacağı, daha uzun saklama gerekiyorsa yasal dayanağının belirtilmesi
• Müşteri adı, adres gibi hangi bilgilere ihtiyacınız olduğu

Politika Referansı: Data Protection Policy 2.1 - PII verileri yalnızca sipariş teslimi, vergi hesaplama, fatura oluşturma ve yasal gereksinimler için kullanılabilir

Ağ koruma kontrollerini açıklayın
Ne Beklenir:

• Firewall kullanımı (marka ve model belirtin)
• Anti-virüs ve anti-malware/EDR yazılımları ve güncelleme sıklığı (otomatik değilse en az aylık)
• Yetkisiz IP adreslerine erişim engelleme
• IDS (Intrusion Detection System) ve IPS (Intrusion Prevention System) kullanımı
• İnternete açık uç noktalar için WAF veya eşdeğeri uygulama katmanı koruması

Politika Referansı: Data Protection Policy 1.1 - Network Protection

Çalışanların Amazon bilgilerine erişimini nasıl kısıtlıyorsunuz
Ne Beklenir:

• Paylaşılan hesapların kullanılmadığı
• Rol bazlı erişim kontrolü (RBAC)
• Tüm kullanıcı hesapları için MFA uygulandığı
• Çalışan ayrıldığında erişimin 24 saat içinde kapatılması
• 3 ayda bir erişim listelerinin gözden geçirilmesi
• En fazla 10 başarısız giriş denemesinden sonra hesap kilitleme uygulandığı
• Onaylı Kullanıcılar için yılda en az bir kez veri koruma/BT güvenliği eğitimi verildiği

Politika Referansı: Data Protection Policy 1.2 - Access Management, 1.3 - Least Privilege Principle

Kişisel cihazlardan (USB, telefon) erişimi nasıl engelliyorsunuz
Ne Beklenir:

• USB portlarının yazılımla engellenmesi
• Kişisel/yönetilmeyen cihazlardan erişimin MDM/UEM gibi araçlarla yönetilmediği sürece kısıtlandığı
• DLP (Data Loss Prevention) kontrolleri
• Olay durumunda nasıl uyarı aldığınız
• Ekran kilidinin en fazla 15 dakika hareketsizlik sonrası otomatik devreye girdiği

Politika Referansı: Data Protection Policy 2.3 - Asset Management

Gizlilik ve veri işleme politikanızı paylaşın
Ne Beklenir:

• Verilerin nasıl toplandığı, işlendiği, saklandığı
• Verilerin nasıl silineceği (NIST 800-88 gibi standartlara uygunluk)
• KVKK Aydınlatma Metni, Gizlilik Politikası URL'i
• Üçüncü taraflarla veri paylaşımı (varsa)
• Veri işleme faaliyetleri kaydının (hangi alanların nasıl işlendiği) tutulduğu
• PII işleyen personelin iş sözleşmelerinde gizlilik yükümlülüğü maddesi bulunduğu

Politika Referansı: Data Protection Policy 2.2 - Data Governance

Bekleyen (at rest) verileri nasıl şifreliyorsunuz
Ne Beklenir:

• Şifreleme algoritması ve anahtar uzunluğu (minimum AES-128 veya RSA-2048)
• Verilerin nerede saklandığı (veri tabanı, sunucu)
• Anahtar yönetim sistemi (KMS) ve tam yaşam döngüsü yönetimi (üretim, değişim, depolama, iptal, rotasyon)
• Anahtarların düzenli rotasyonu
• Programatik kimlik bilgilerinin (API anahtarları) şifrelenmesi ve en az 12 ayda bir rotasyonu

Politika Referansı: Data Protection Policy 2.4 – Encryption at Rest

Yedekleme ve arşivleme işlemlerini açıklayın
Ne Beklenir:

• Yedekleme şifresi (minimum AES-128 veya RSA-2048)
• Coğrafi olarak ayrı yedekleme konumu
• RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) süreleri
• Yedekleme sıklığı
• PII verileri için 30 günlük süre açıklaması (yasal zorunluluk sebebiyle daha uzun saklamanız halinde bunun nedenini açıklayın)

Politika Referansı: Data Protection Policy 1.5 – Encryption in Transit, 2.1 – Data Retention

Güvenlik loglarını nasıl tutuyorsunuz
Ne Beklenir:

• Log tutma süresi (minimum 12 ay)
• Real-time izleme veya haftalık/iki haftalık inceleme
• Loglarda PII tutulmadığı
• Şüpheli aktivitelerde nasıl uyarı aldığınız
• Logların değiştirilemez formatta saklanması
• Real-time izleme veya en az iki haftada bir inceleme
• Çoklu yetkisiz çağrı, beklenmeyen istek hacmi ve canary veri kayıtlarına erişim gibi şüpheli aktivitelerde nasıl uyarı aldığınız
• Bilginin korunan sınırlar dışında (örn. Dark Web) tespit edilmesine yönelik izleme mekanizması

Politika Referansı: Data Protection Policy 2.6 – Logging and Monitoring

Olay müdahale planınızı özetleyin
Ne Beklenir:

• Güvenlik ihlali durumunda atılacak adımlar
• Amazon'a 24 saat içinde bildirim ([email protected])
• Risk değerlendirmesinin üst yönetim tarafından en az yılda bir gözden geçirildiği
• IMPOC (Incident Management Point of Contact) kişi bilgileri
• Plan gözden geçirme sıklığı (6 ayda bir) ve önemli değişikliklerden sonra ek gözden geçirme

Politika Referansı: Data Protection Policy 1.6 - Risk Management and Incident Response Plan

Şifre yönetimi politikanız nedir
Ne Beklenir:

• Minimum 12 karakter
• Büyük/küçük harf, rakam, özel karakter zorunluluğu
• Minimum 1 gün / maksimum 365 gün şifre yaşı
• Tüm hesaplar için MFA (Multi-Factor Authentication) kullanımı
• Son 10 şifrenin tekrar kullanılmasının engellenmesi (şifre geçmişi)
• Kullanıcı adını içermeme

Politika Referansı: Data Protection Policy 1.4 - Credential Management

Test ortamında PII nasıl korunuyor
Ne Beklenir:

• Canlı müşteri verisi kullanılmadığı
• Test ve production ortamlarının ayrı olduğu
• Hassas verilerin kodlara gömülmediği
• Test verileri için maskeleme/anonimleştirme

Politika Referansı: Data Protection Policy 2.5 - Secure Coding Practices

Kimlik bilgilerinin açığa çıkmasını nasıl engelliyorsunuz
Ne Beklenir:

• Kimlik bilgilerinin şifrelenmesi (AES-256, SHA-256 vb.)
• Public repolar'da hassas bilgi bulunmaması
• Erişim kontrolü ve maskeleme
• API anahtarlarının güvenli saklanması ve en az 12 ayda bir rotasyonu

Politika Referansı: Data Protection Policy 2.5 - Secure Coding Practices

Kaç günde bir güvenlik açığı taraması ve penetrasyon testi yapılıyor
Ne Beklenir:

• Güvenlik açığı taramasının en az 30 günde bir yapıldığı
• Önemli değişikliklerden sonra ek (değişiklik tetiklemeli) tarama yapıldığı
• Penetrasyon testi sıklığı
• Her sürümden önce kod taraması
• Kritik açıkların 7 gün, yüksek riskli açıkların 30 gün içinde giderildiği
• Takip mekanizması
• Sızma testinin en az 365 günde bir, endüstri standardı bir metodolojiyle yapıldığı

Politika Referansı: Data Protection Policy 2.7 - Vulnerability Management

Değişiklik yönetiminden kimler sorumlu
Ne Beklenir:

• Sorumlu kişilerin isimleri, unvanları ve e-posta adresi
• Erişim nasıl verildiği (VPN, firewall kuralları vb.)
• Değişikliklerin test edilmesi ve onaylanması; onaylayan ile testi yapan kişiler arasında görevler ayrılığı (segregation of duties) bulunduğu

Sık Sorulan Sorular

1. Tüm kamu geliştiricilerinin hem DARF hem de SA Değerlendirmesini tamamlaması gerekir mi?
   Hayır. Tüm kamu geliştiricileri DARF incelemesini tamamlamalıdır. SA Değerlendirmesi YALNIZCA PII'ye erişim sağlayan kısıtlı roller talep ederseniz gereklidir. Yalnızca kısıtlı olmayan roller talep ederseniz, SA Değerlendirmesini tamamen atlayacaksınız.
2. SA Değerlendirme görüşmesine kimler katılmalıdır?
   Güvenlik ekibiniz, uyumluluk görevlileriniz, sistem mimarlarınız ve veri işleme ve korumayla ilgili herkes dahil olmak üzere teknik altyapınız hakkında kapsamlı bilgiye sahip ekip üyelerini dahil etmelisiniz. Bu kişiler güvenlik kontrollerinizi tartışabilmeli ve potansiyel olarak gösterebilmelidir.
3. SA Değerlendirmesi sırasında tespit edilen güvenlik açıklarımız varsa ne olur?
   Bu beklenen bir durumdur ve sürecin bir parçasıdır. Amazon, belirli zaman dilimleri olan bir iyileştirme planı geliştirmek için sizinle çalışacaktır. Duyarlı kalmalı ve gerekli kontrolleri uygulamalısınız. Amazon'un çözüm mimarları, iyileştirme süreci boyunca rehberlik sağlayacaktır.
4. Tüm kayıt süreci ne kadar sürer?
   Zaman çizelgesi hazırlığınıza ve yanıt verme hızınıza bağlı olarak değişir. Profiliniz tamamsa ve web siteniz gereksinimleri karşılıyorsa DARF incelemesi genellikle 1-2 hafta sürer. SA Değerlendirmesi (gerekirse) altyapınızın karmaşıklığına ve gerekli herhangi bir iyileştirmeye bağlı olarak 3-6 hafta ekler. Ancak bu süre yanıtlarınızın yeterliliğine göre uzayabilir.
5. Kaydı tamamlamadan önce geliştirmeye başlayabilir miyiz?
   Evet. Kayıt sırasında sandbox ortamında geliştirme ve test yapabilirsiniz. Ancak, onay alıp tüm gerekli incelemeleri tamamlayana kadar üretim verilerine erişemez veya satıcı hesaplarını yetkilendiremezsiniz.
6. Gelecekte yeniden değerlendirmeye ihtiyacımız olacak mı?
   Evet. Amazon, ortaya çıkan tehditleri ve en iyi uygulamaları ele almak için güvenlik çerçevesini düzenli olarak günceller. Çerçeve güncellemelerine, altyapınızdaki önemli değişikliklere veya sürekli uyumu sağlamak için Amazon'un takdirine bağlı olarak yeniden değerlendirmeler başlatılabilir.
7. Teknik değerlendirme görüşmesine nasıl hazırlanmalıyız?
   • Güvenlik kontrollerini gösterebilecek teknik personele sahip olun
   • Altyapınızı, kayıtlarınızı ve izleme sistemlerinizi ekran paylaşımına hazırlayın
   • Tüm değerlendirme alanlarını inceleyin ve örnekleri hazır bulundurun
   • İlgili sistemlere ve dokümantasyona erişim sağlayın
   • Kontrollerin gerçek uygulamasını adım adım göstermeye hazır olun