Docker Daemon Sıkılaştırmaları

Zararlı İmajlar

Bu bölüm Docker ile ilgili dosya ve dizinlerin izinlerini ve sahipliğini kapsamaktadır. Hassas parametreler içerebilen dosya ve dizinlerin saklanması, Docker daemonunun doğru ve güvenli çalışması için önemlidir.

“Docker.Service” Dosyası Sahipliğinin Root:Root Olması

Docker.service dosyası Docker daemon davranışını değiştirebilecek hassas parametreler içerir. Bu nedenle, dosyanın bütünlüğünü korumak için sahip olunması ve gruba ait olması gerekir.

Docker.service dosyasını root:root olarak düzenlemek için:

$ chown root:root /usr/lib/systemd/system/docker.service

“Docker.service” Dosya İzinlerinin 644 Veya Daha Kısıtlayıcı Olarak Ayarlanması

Docker.service dosyası Docker daemon davranışını değiştirebilecek hassas parametreler içerir. Bu nedenle, dosyanın bütünlüğünü korumak için root dışındaki herhangi bir kullanıcı tarafından yazılabilir olmamalıdır.

Düzenlemek için:

$ chmod 644 /usr/lib/systemd/system/docker.service

“Docker.Socket” Dosyası Sahipliğinin Root:Root Olması

Docker.socket dosyası, Docker API’sinin davranışlarını değiştirebilecek hassas parametreler içerir. Bu nedenle, dosyanın bütünlüğünü korumak için sahip olunması ve gruba ait olması gerekir.

Düzenlemek için:

$ chown root:root /usr/lib/systemd/system/docker.socket

  1. https://docs.docker.com/engine/reference/commandline/ dockerd/#daemon- socket-option
  2. ce/blob/master/ components/packaging/deb/systemd/docker.socket

“Docker.Socket” Dosya İzinlerinin 644 Veya Daha Kısıtlayıcı Olarak Ayarlanması

docker.socket dosyası Docker daemon davranışını değiştirebilecek hassas parametreler içerir. Bu nedenle, dosyanın bütünlüğünü korumak için root dışındaki herhangi bir kullanıcı tarafından yazılabilir olmamalıdır.

Düzenlemek için:

  1. https://docs.docker.com/engine/reference/commandline/ dockerd/#bind-docker- to-another-hostport-or-a-unix-socket
  2. packer/ blob/master/oem/docker.socket
  3. centos-7rhel-7-and-docker-containers- on-boot/

“/etc/docker” Dizini Sahipliğinin Root:Root Olması

“/etc/docker” dizini çeşitli hassas dosyalara ek olarak sertifikalar ve anahtarlar içerir. Bu nedenle, dizinin bütünlüğünü korumak için sahip olunması ve gruba ait olması gerekir.

Düzenlemek için:

$ chown root:root /etc/docker

  1. https://docs.docker.com/engine/security/https/

“/etc/docker” Dizin İzinlerinin 755 Veya Daha Kısıtlayıcı Olarak Ayarlanması

/etc/docker dizini çeşitli hassas dosyalara ek olarak sertifikalar ve anahtarlar içerir. Bu nedenle, yalnızca dizinin bütünlüğünü korumak için kök tarafından yazılabilir olmalıdır.

Düzenlemek için:

$ chmod 755 /etc/docker

  1. https://docs.docker.com/engine/security/https/

Registry Sertifikasının Sahipliğinin Root:Root Olması

/etc/docker/certs.d/ <kayıt defteri-adı> dizini Docker kayıt defteri(registry) sertifikalarını içerir. Sertifikaların bütünlüğünü korumak için bu sertifika dosyaları sahiplenmeli ve gruba ait olmalıdır.

Düzenelemek için:

$ chown root:root /etc/docker/certs.d/<registry-name>/*

  1. https://docs.docker.com/registry/insecure/

Registry Sertifikalarının Dosya İzinlerinin 444 Veya Daha Kısıtlayıcı Olması

Tüm kayıt defteri sertifikası dosyalarının (genellikle /etc/docker/certs.d/ <kayıt defteri-adı> dizininde bulunur) 444 veya daha fazla kısıtlayıcı izinlere sahip olduğunu doğrulayın.

Düzenlemek için:

$ chmod 444 /etc/docker/certs.d/<registry-name>/*

TLS CA Sertifikasının Dosya Sahipliğinin Root:Root Olması

TLS CA sertifika dosyası herhangi bir değişiklikten korunmalıdır. Verilen CA sertifikasına dayalı Docker sunucusunu doğrulamak için kullanılır. Bu nedenle, CA sertifikasının bütünlüğünü korumak için sahip olunması ve gruba ait olması gerekir.

Düzenlemek için:

$ chown root:root <path to TLS CA certificate file>

TLS CA Sertifikasının Dosya İzinlerinin 444 Veya Daha Kısıtlayıcı Olması

TLS CA sertifika dosyası herhangi bir değişiklikten korunmalıdır. Verilen CA sertifikasına dayalı Docker sunucusunu doğrulamak için kullanılır. Bu nedenle, CA sertifikasının bütünlüğünü korumak için 444 izinlerine sahip olmalıdır.

Düzenlemek için:

$ chmod 444 <path to TLS CA certificate file>

Docker Server Sertifika Sahipliğinin Root:Root Olması

Docker sunucusu sertifika dosyası herhangi bir değişiklikten korunmalıdır. Verilen sunucu sertifikasına dayalı Docker sunucusunu doğrulamak için kullanılır. Bu nedenle, sertifikanın bütünlüğünü korumak için sahip olunması ve gruba ait olması gerekir.

Düzenlemek için:

$ chown root:root <path to Docker server certificate file>

Docker Server Sertifikası Dosya İzinlerinin 444 Veya Daha Kısıtlayıcı Olması

Docker sunucusu sertifika dosyası herhangi bir değişiklikten korunmalıdır. Verilen sunucu sertifikasına dayalı Docker sunucusunu doğrulamak için kullanılır. Bu nedenle, sertifikanın bütünlüğünü korumak için 444 izinleri olmalıdır.

Düzenlemek için:

$ chmod 444 <path to Docker server certificate file>

Docker Server Sertifika Key Sahipliğinin Root:Root Olması

Docker sunucu sertifikası anahtar dosyası, herhangi bir kurcalama veya gereksiz okumalardan korunmalıdır. Docker sunucu sertifikası için özel anahtarı tutar. Bu nedenle, Docker sunucu sertifikasının bütünlüğünü korumak için sahip olunması ve gruba ait olması gerekir.

Düzenlemek için:

$ chown root:root <path to Docker server certificate key file>

Docker Server Sertifika Key Dosya İzinlerinin 400 Veya Daha Kısıtlayıcı Olması

Docker sunucu sertifikası anahtar dosyası, herhangi bir kurcalama veya gereksiz okumalardan korunmalıdır. Docker sunucu sertifikası için özel anahtarı tutar. Bu nedenle, Docker sunucu sertifikasının bütünlüğünü korumak için 400 izinlerine sahip olmalıdır.

Düzenlemek için:

$ chmod 400 <path to Docker server certificate key file>

“Daemon.Json” Sahipliğinin Root:Root Olması

Daemon.json dosyası, docker daemon davranışını değiştirebilecek hassas parametreler içerir. Bu nedenle, dosyanın bütünlüğünü korumak için sahip olunması ve gruba ait olması gerekir.

Düzenlemek için:

$ chown root:root /etc/docker/daemon.json

“Daemon.Json” Dosya İzinlerinin 644 Veya Daha Kısıtlayıcı Olması

daemon.json dosyası, docker daemon davranışını değiştirebilecek hassas parametreler içerir. Bu nedenle, dosyanın bütünlüğünü korumak için yalnızca kök tarafından yazılabilir olmalıdır.

Düzenlemek için:

$ chmod 644 /etc/docker/daemon.json

“/etc/default/docker” Sahipliğinin Root:Root Olması

/ etc / default / docker dosyası, docker daemon davranışını değiştirebilecek hassas parametreler içerir. Bu nedenle, dosyanın bütünlüğünü korumak için sahip olunması ve gruba ait olması gerekir.

Düzenlemek için:

$ chown root:root /etc/default/docker

“/etc/default/docker” Dosya İzinlerinin 644 Veya Daha Kısıtlayıcı Olması

/ etc / default / docker dosyası, docker daemon davranışını değiştirebilecek hassas parametreler içerir. Bu nedenle, dosyanın bütünlüğünü korumak için yalnızca kök tarafından yazılabilir olmalıdır.

Düzenlemek için:

$ chmod 644 /etc/default/docker

Konteyner İmajları Ve İmaj Build Sıkılaştırmaları

Konteyner imajları ve imaj build dosyaları, konteynerlerin nasıl davranacağının temellerini oluşturur. Uygun imajlar ve uygun build dosyalarını kullandığınızdan emin olmak konteyner altyapınızı oluşturmak için çok önemli olmaktadır. Aşağıda, konteyner imajları için izlemeniz gereken önerilerden bazıları ve konteynerize edilmiş altyapınızın güvenli olduğundan emin olmak için bazı öneriler bulunmaktadır.

Dockerfile içerisinde Root Dışında Bir Kullanıcı Tanımlamak

Mümkünse, konteyneri root olmayan bir kullanıcı olarak çalıştırmak iyi bir uygulamadır. User namespace eşleştirmesi artık kullanılabilir olsa da, bir kullanıcı konteyner imajında zaten tanımlanmışsa, konteyner varsayılan olarak bu kullanıcı olarak çalıştırılır ve belirli namespaceleri yeniden eşlemesi gerekmez.

Örneğin, Dockerfile içerisine aşağıdaki gibi bir satır eklemek konteynerinizi oluştururken bir kullanıcı eklemenizi sağlar.

RUN useradd -d /home/username -m -s /bin/bash username USER username

Varsayılan olarak, kapsayıcılar root yetkileri ile çalıştırılır ve kullanıcı olarak root kullanır.

Güvenilir Konteyner Base İmajlarının Kullanılması

Resmi depolar, Docker topluluğu veya satıcı tarafından düzenlenmiş ve optimize edilmiş imajlardır. Potansiyel olarak güvenli olmayan diğer kamu depoları da kullanılabilir. Docker’dan ve üçüncü şahıslardan kuruluşunuzun verileri için nasıl kullanılacağına dair konteyner imajları indirilirken dikkatli olunmalıdır. (Konu ile ilgili yukarıda düzenlemiş olduğumuz başlık incelenebilir)

Konteynerlere Gereksiz Paketlerin Yüklenmemesi

Gereksiz yazılımlara sahip şişkin konteynerler ve konteynerlerin saldırı yüzeyini artırabilmektedir. Bu aynı zamanda konteyner imajlarının minimal olmasını da engellemektedir. Bu nedenle, konteynerin amacı için gerçekten gerekli olandan başka hiçbir şey yüklemeyin.

Konteynerlerin Güvenlik Taramalarından Geçirilmesi Ve Patchleme

İmajlar herhangi bir güvenlik açığı için “sık sık” olarak taranmalıdır. İmajlar yamaları içerecek şekilde yeniden oluşturulmalı ve yeniden başlatılmalıdır.

“HEALTHCHECK” Parametresinin Aktifleştirilmesi

Çalışan konteyner kontrollerini gerçekleştirmek için docker konteyner imajlarına HEALTHCHECK talimatı ekleyin.

Kontrol için:

$ docker inspect –format='{{ .Config.Healthcheck }}’ <IMAGE>

Setuid and Setgid İzinlerinin İmajlardan Silinmesi

İmajlarda setuid ve setgid izinlerinin kaldırılması, konteynerde yetksi yükseltme saldırılarını önleyecektir. Setuid ve setgid izinleri yetki yükseltmek için kullanılabilir. Bu izinler zaman zaman gerekli olsa da, potansiyel olarak yetki yükseltme saldırılarında kullanılabilmektedir. Bu nedenle, bu izinler onlara ihtiyaç duyulmadığı sürece kullanılmamalıdır.

Setuid ve SetGid izinlerini bulunan çalıştırılabilir dosyaları bulmak için:

$ docker run <Image_ID> find / -perm +6000 -type f -exec ls -ld {} \; 2> /dev/null

Dockerfile’ın sonuna doğru aşağıdaki komutu ekleyerek, oluşturma sırasında bu izinleri kaldırabilirsiniz:

RUN find / -perm +6000 -type f -exec chmod a-s {} \; || true

  1. uploads/2015/06/15.06.15_DockerCheatSheet_A2.pdf
  2. http://man7.org/linux/man-pages/man2/setuid.2.html
  3. http://man7.org/linux/man-pages/man2/setgid.2.html

Dockerfile İçerisinde “ADD” yerine “COPY” Kullanımı

COPY komutu, dosyaları yerel ana bilgisayardan konteyner dosya sistemine kopyalar. “ADD” komutu, potansiyel olarak uzak URL’lerden dosya alabilir ve paket açma gibi işlemleri gerçekleştirebilir. Bu nedenle, ADD komutu, URL’lerden zararlı yazılımları eklemek  gibi riskleri ortaya çıkarır.

Önlem:

ADD yerine COPY kullanılması gerekmektedir.

  1. practices/#add-or-copy

Doğrulanmış Paketlerin Kullanımı

İmajları yüklemeden önce paketlerin doğrulanması gerekmektedir. Paketleri doğrulamak, güvenli bir konteyner imajı oluşturmak için gereklidir. Bozuk paketler potansiyel olarak zararlı olabilir veya kötüye kullanılabilecek bazı bilinen güvenlik açıkları bulundurabilir.

Konteyner Çalışma Zamanı Sıkılaştırmaları

AppArmor’un Aktifleştirilmesi

AppArmor etkili ve kullanımı kolay bir Linux uygulama güvenlik sistemidir. Debian ve Ubuntu gibi varsayılan olarak birkaç Linux dağıtımında kullanılabilir. AppArmor, aynı zamanda AppArmor profili olarak da bilinen güvenlik politikasını uygulayarak uygulamaları çeşitli tehditlerden korur. Konteynerler için kendi AppArmor profilinizi oluşturabilir veya Docker’ın varsayılan AppArmor profilini kullanabilirsiniz.

Kontrol için:

$ docker ps –quiet –all | xargs docker inspect –format ‘{{ .Id }}: AppArmorProfile={{ .AppArmorProfile }}’

AppArmor Linux işletim sisteminiz için uygunsa, onu kullanın. Aşağıdaki adımları uygulayın:

  1. AppArmor’un kurulu olup olmadığını kontrol edin. Değilse, kurun.
  2. Docker konteynerleri için bir AppArmor profili oluşturun veya bulun.
  3. Bu profili zorlama(encorfing) moduna geçirin.
  4. Docker kotneynerinizi özelleştirilmiş AppArmor profilini kullanarak başlatın. Örneğin,

$ docker run –interactive –tty –security-opt=”apparmor:PROFILENAME” centos /bin/bash

  1. https://docs.docker.com/engine/security/apparmor/
  2. https://docs.docker.com/engine/reference/run/#security-configuration
  3. https://docs.docker.com/engine/security/security/#other-kernel-security-features

SELinux’un Aktifleştirilmesi

SELinux etkili ve kullanımı kolay bir Linux uygulama güvenlik sistemidir. Red Hat ve Fedora gibi varsayılan olarak birkaç Linux dağıtımında mevcuttur. SELinux, varsayılan İsteğe Bağlı Erişim Denetimi (DAC) modelini büyük ölçüde artıran bir Zorunlu Erişim Denetimi (MAC) sistemi sağlar. Bu nedenle, eğer varsa, Linux sunucunuzda SELinux’u etkinleştirerek fazladan bir güvenlik katmanı ekleyebilirsiniz.

Kontrol:

 $ docker ps –quiet –all | xargs docker inspect –format ‘{{ .Id }}: SecurityOpt={{ .HostConfig.SecurityOpt }}’

SELinux Linux işletim sisteminiz için uygunsa, kullanın. Aşağıdaki adımları uygulamanız gerekebilir:

  1. SELinux Durumunu ayarlayın.
  2. SELinux Politikasını ayarlayın.
  3. Docker konteynerler için bir SELinux şablonu oluşturun veya bulun.
  4. SELinux etkin olarak Docker daemon modunu başlatın. Örneğin,

$ docker daemon –selinux-enabled

Konteyner için:

$docker run –interactive –tty –security-opt label=level:TopSecret centos /bin/bash

  1. https://docs.docker.com/engine/security/security/#other-kernel-security-features
  2. https://docs.docker.com/engine/reference/run/#security-configuration

us/red_hat_enterprise_linux_atomic_host/7/html/ container_security_guide/docker_ selinux_security_policy

Privileged (Ayrıcalıklı) Konteynerlerin Kullanılmaması

“–privileged” parametresini kullanmak, tüm Linux Kernel kabiliyetlerini konteynere verir ve böylece “–cap-add” ve “–cap-drop” parametreleri geçersiz olur. Kullanılmadığından emin olun.

“Privileged” parametresi tüm yetenekleri konteynere verir ve tüm sınırlamaları kaldırır. Başka bir deyişle, konteyner host(ana) makinenin yapabileceği neredeyse her şeyi yapabilir. Bu parametre, Docker’da Docker’ı çalıştırmak gibi özel kullanım durumlarına izin vermek için var.

Kontrol için:

$ docker ps –quiet –all | xargs docker inspect –format ‘{{ .Id }}: Privileged={{ .HostConfig.Privileged }}’

Önlem:

–privileged parametresi ile konteynerleri çalıştırmayın, örneğin:

$ docker run –interactive –tty –privileged centos /bin/bash

Ana (host) Sunucunun Sistem Dizinlerinin Mount Edilmemesi

Aşağıdaki gibi hassas ana sunucu sistem dizinlerinin özellikle okuma-yazma(read-write) modunda konteyner birimlere olarak mount edilmesine izin verilmemelidir.

 

Hassas dizinler okuma-yazma modunda mount edilirse, bu hassas dizinlerdeki dosyalarda değişiklik yapmak mümkün olabilir. Değişiklikler, Docker ana sunucusunu tehlikeye sokabilir ve gereksiz değişikliklere neden olabilir.

/
/boot
/dev
/etc
/lib
/proc
/sys
/usr

Kontrol için:

$ docker ps –quiet –all | xargs docker inspect –format ‘{{ .Id }}: Volumes={{ .Mounts }}

Konteyner içerisinde SSH Servisinin Kapatılması

SSH konteynerde çalıştırılmamalıdır. Docker ana bilgisayarına SSH yapmalı ve uzak bir ana bilgisayardan bir konteynere girmek için nsenter aracını kullanabilirsiniz.

Konteynerde Sadece Gerekli Portların Açık Olması

Bir konteyner, sadece Dockerfile dosyasında tanımlanan portlar ile çalıştırılabilir veya ilgili çalışma parametrelerinde belirtilen portları kullanabilir. Dockerfile çeşitli değişikliklere uğrayabilir ve açıkta bulunan bağlantı noktaları listesi konteyner içinde çalıştığınız uygulama ile ilgili olabilir veya olmayabilir. Gereksiz portların açılması konteynerin ve konteyner uygulamasının saldırı yüzeyini arttırır. Önerilen bir uygulama olarak, gereksiz portları açmayın.

Kontrol için:

$ docker ps –quiet | xargs docker inspect –format ‘{{ .Id }}: Ports={{ .NetworkSettings.Ports }}’

  1. https://docs.docker.com/engine/userguide/networking/

Konteynerlerin HOST Networkünü Kullanmaması

–net=host parametresi ayarlandığında bir konteyner ağ modu devre dışı kalır. Bu seçenek Docker’a, konteynerin ağını kapatmasını söyler. Konteyner Docker ana bilgisayarında “dışarıda” çalışmasına sebep olur ve ana bilgisayarın ağ arabirimlerine tam erişime sahip olduğu anlamına gelir. Bu potansiyel olarak tehlikelidir. Konteynerin diğer herhangi bir portu açmasına izin verir. Ayrıca konteynerin Docker ana bilgisayarındaki D-bus gibi ağ servislerine erişmesini de sağlar. Böylece, bir konteyner processi, Docker ana bilgisayarını kapatmak gibi beklenmedik şeyler yapabilir. Bu seçeneği kullanmamalısınız.

Kontrol için:

$ docker ps –quiet –all | xargs docker inspect –format ‘{{ .Id }}: NetworkMode={{ .HostConfig.NetworkMode }}’

Konteyner Trafiğinin Bir Network Arayüzüne Bind Edilmesi

Ana makinenizde birden çok ağ arabiriminiz varsa, konteyner, herhangi bir ağ arabirimindeki açılmış portlardan bağlantıları kabul edebilir. Bu istenmeyebilir ve güvenli olmayabilir. Bir arayüzün birden fazla arayüze eriştiği IDS,IPS, Firewall, Load balancer gibi hizmetler dışında gereksiz olmaktadır.  Bu Hizmetler, gelen toplu trafiği taramak için bu arayüzler üzerinde çalıştırılır. Bu nedenle, herhangi bir arayüzden gelen tüm bağlantıları kabul etmemelisiniz. Sadece belirli bir arayüzden gelen bağlantılara izin vermelisiniz.

Kontrol ve Port Mapping için:

$ docker ps –quiet | xargs docker inspect –format ‘{{ .Id }}: Ports={{ .NetworkSettings.Ports }}

Listeyi gözden geçirin ve açık konteyner portlarının belirli bir arayüze bağlı olduğundan emin olunuz – IP adresinin – 0.0.0.0 olmaması gerekmektedir.

Konteyneri spesifik bir ağ ve port için çalıştırmak için:

$ docker run –detach –publish 10.2.3.4:49153:80 nginx

Yukarıdaki örnekte, konteyner 80 portu 49153’teki host portuna bağlanır ve sadece 10.2.3.4 network arayüzden gelen bağlantıyı kabul eder.

  1. https://docs.docker.com/engine/userguide/networking/

Docker0 Ağ Arayüzünün Kullanılmaması

Docker’ın varsayılan köprüsü docker0 kullanmayın. Konteyner ağ bağlantısı için docker’ın kullanıcı tanımlı ağlarını kullanın. Docker, köprü modunda oluşturulan sanal arabirimleri docker0 adlı ortak bir köprüye bağlar. Bu varsayılan ağ modeli, filtreleme uygulanmadığından ARP spoofing ve MAC flooding saldırılarına karşı savunmasızdır.

Kontrol için:

$ docker network ls –quiet | xargs xargs docker network inspect –format ‘{{ .Name }}: {{ .Options }}’

  1. https://github.com/nyantec/narwhal
  2. https://docs.docker.com/engine/userguide/networking/

Docker’da Bulunan Geçmiş Zafiyetler

Docker’ın piyasaya sürülmesinden bu yana, işlevselliğini ve güvenliğini artırmak için bir dizi güncelleme ve değişiklik yapılmıştır Yine de, herhangi bir programcının bildiği gibi, kesinlikle güvenli bir platform yoktur ve Docker bir istisna değildir. Ayrıca, çoğu zaman, güvenlik, bir kullanıcının Docker ile nasıl etkileşim kurduğundan etkilenir ve bu da insani hatalarla ilgili birkaç sorunla karşılaşmaktadır. 2016 yılında Cloud Foundry ) tarafından yürütülen çok sayıda gelişmiş ülkeden 700’ün üzerinde şirketin yer aldığı bir çalışmada şirketlerin yarısının konteyner teknolojsini kullandığını göstermektedir.

Bunların arasında %64’ü ise konteyner teknolojisinin kullanımını yaygınlaştırmayı planlamaktadır. Konteyner kullanımındaki bu hızlı artışa bakıldığında, yeni güvenlik sorunları da sürekli olarak ortaya çıkmaktadır. Docker, günümüzde en çok kullanılan konteyner teknolojisidir ve diğer benzer platformlarda olduğu gibi, birçoğu protokole özgü olan güvenlik sorunlarına sahiptir. Daha önce Docker’da bulunmuş olan zafiyetlerin listesi CVE-List üzerinden gözlemlenebilir ve bu güvenlik sorunları hakkında bilgi edinilebilir.

Geçmiş Zafiyetler Listesi:

  • https://www.cvedetails.com/vulnerability-list/vendor_id-13534/product_id-28125/Docker-Docker.html

Kaynaklar:

  • https://rhelblog.redhat.com/2016/10/17/secure-your-containers-with-this-one-weird-trick/
  • https://www.cisecurity.org/benchmark/docker/
  • https://rhelblog.redhat.com/2016/10/17/secure-your-containers-with-this-one-weird-trick/
  • https://rhelblog.redhat.com/2017/01/13/selinux-mitigates-container-vulnerability/

Yorum Yaz

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

*
*

sixteen − eleven =

Mail listemize üye olarak eğitim fırsatlarını kaçırmayın!
Eğitim ve ücretsiz etkinliklerizden haberdar olmak için e-posta listesimize üye olun!.
Duyuru Listemize Kayıt

25.000 profesyonel; eğitim, etkinlik ve kampanyalarımızdan haberdar oluyor. Sizi de bu listeye dahil etmemizi ister misiniz?