MariaDB SSL/TLS ile Şifreli Bağlantı: Sunucu, İstemci ve REQUIRE SSL

SSL mi TLS mi?

Belgeler terimi şöyle açıklar: TLS'in eski adı SSL'dir, ama kesin konuşmak gerekirse SSL protokolü TLS'in güvensiz kabul edilen öncülüdür. MariaDB içeride yalnızca güvenli halefleri destekler. Uyumluluk nedeniyle sistem ve durum değişkenleri hâlâ ssl_ ön ekini taşır ve belgelerde de SSL sözcüğü sık geçer. Bu yazıda ikisini aynı anlamda kullanacağız; seçenek adları ise belgelerdeki gibi ssl_ ile yazılıyor.

Sunucunun TLS durumunu kontrol etmek

Sunucunun TLS desteğiyle derlenip derlenmediğini ve TLS'in etkin olup olmadığını have_ssl değişkeni gösterir. Belgelere göre MariaDB Foundation ve MariaDB Corporation'ın dağıttığı tüm paketler TLS desteğiyle derlenmiştir.

SHOW GLOBAL VARIABLES LIKE 'have_ssl';

Tek tek bağlantıların şifreli olup olmadığını ise oturumun Ssl_version durum değişkeni söyler: TLS kullanılıyorsa sürümü gösterir, şifreleme yoksa boştur. Belgelerdeki örnek çıktı:

SHOW SESSION STATUS LIKE 'Ssl_version';
+---------------+---------------------------+
| Variable_name | Value                     |
+---------------+---------------------------+
| Ssl_version   | TLSv1.3                   |
+---------------+---------------------------+
1 row in set (0.00 sec)

Sıfır yapılandırmalı TLS (MariaDB 11.4 ve sonrası)

Eskiden TLS açmak; özel anahtar üretmek, sertifika isteği oluşturmak ve bir sertifika otoritesi (CA) yönetmek demekti ve belgelerin de belirttiği gibi bu karmaşıklık yüzünden birçok kurulum şifresiz kalıyordu. MariaDB 11.4 ile gelen sıfır yapılandırmalı TLS iki şey yapar: sunucuda sertifika yoksa açılışta kendinden imzalı bir sertifika üretilir ve yalnızca bellekte tutulur; istemci ise sunucunun kimliğini bir CA'ya değil, hesabın parolasına dayanarak doğrular.

Doğrulamanın mantığı belgelerde adım adım anlatılır. İstemci sunucunun kendinden imzalı sertifikasıyla TLS bağlantısı kurar ve sertifikanın SHA256 parmak izini hesaplar. Ardından bu parmak izi ve kullanıcının parolasından bir imza üretir; sunucu da aynı hesabı yapar. Değerler eşleşirse istemci doğru sunucuyla konuştuğundan emin olur. Araya giren biri farklı bir sertifika sunacağı için parmak izi değişir ve kullanıcının parolasını bilmeden bu farkı kapatamaz.

• Gereksinim: Hem sunucu hem istemci 11.4 ya da üstü olmalıdır. İstemcide --ssl-verify-server-cert varsayılan olarak açıktır.
• Desteklenen eklentiler: mysql_native_password, ed25519 ve parsec; bunlar TLS olmadan da ortadaki adam saldırısına dayanıklıdır.
• Sınır: PAM, GSSAPI ve caching_sha2_password TLS olmadan güvenli değildir, bu yüzden TLS'i doğrulamak için kullanılamaz; bunlarla klasik CA tabanlı doğrulama kullanılmalıdır.
• Yerel bağlantı: Unix soketi üzerinden bağlanırken sertifika otomatik olarak güvenilir sayılır.

Belgeler sıfır yapılandırmalı TLS'in devrede olduğunu görmek için TCP ile, örneğin 127.0.0.1 üzerinden bağlanıp status çıktısındaki SSL satırına bakmayı önerir; çıktıda kullanılan şifre takımı ve sertifikanın geçerli olduğu yazar. İstemci tarafında iki seçenek bu davranışı değiştirir: --disable-ssl TLS'i tamamen kapatır ve önerilmez; --skip-ssl-verify-server-cert doğrulanmamış sertifikaları, hatta tamamen şifresiz bağlantıyı kabul eder ve ortadaki adam saldırısına karşı güvenli değildir.

mariadb -h 127.0.0.1 -u <username> -p

Kimlik doğrulama eklentileri arasındaki farklar kimlik doğrulama yazısında anlatılıyor.

Kendi sertifikanızı üretmek

Kendinden imzalı sertifika ve parolaya dayalı doğrulama çoğu durumda yeterlidir. Ancak PAM gibi eklentiler kullanıyorsanız, istemci sertifikasıyla kimlik doğrulamak istiyorsanız ya da eski istemciler bağlanıyorsa kendi CA'nız ve sertifikalarınız gerekir. Belgelerdeki OpenSSL adımları önce bir CA anahtarı ve sertifikası üretir:

openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca.pem

Ardından sunucu için bir anahtar ve sertifika isteği oluşturulur, anahtardaki parola kaldırılır ve istek CA ile imzalanır:

openssl req -newkey rsa:2048 -days 365000 -nodes -keyout server-key.pem -out server-req.pem
openssl rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 365000 -CA ca.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem

Sertifikanın doğru üretildiğini openssl verify ile kontrol edersiniz; belgelere göre çıktıda OK görmeniz gerekir:

openssl verify -CAfile ca.pem server-cert.pem

server-cert.pem: OK

Sunucuyu sertifikalarla yapılandırmak

Belgeler paketle gelen yapılandırma dosyalarını değiştirmek yerine, ana dosyanın dahil ettiği bir dizinde kendi dosyanızı oluşturmanızı önerir. Dosyalar alfabetik sırayla okunduğu için adını z- ile başlatmak, ayarlarınızın en son okunmasını sağlar: RHEL, Rocky Linux ve SLES'te /etc/my.cnf.d/z-custom-my.cnf, Debian ve Ubuntu'da /etc/mysql/mariadb.conf.d/z-custom-my.cnf. Ayarlar [mariadb], [server] ya da [client-server] gibi sunucunun okuduğu bir gruba yazılır:

[mariadb]
ssl_cert = /etc/my.cnf.d/certificates/server-cert.pem
ssl_key = /etc/my.cnf.d/certificates/server-key.pem
ssl_ca = /etc/my.cnf.d/certificates/ca.pem

ssl_ca ve ssl_capath gibi yol alan değişkenler belgelere göre göreli değil mutlak yol ister. Değişiklikten sonra sunucuyu yeniden başlatın ve have_ssl değerinin YES olduğunu kontrol edin. Seçenek dosyalarının okuma sırası my.cnf yazısında ayrıntılı olarak anlatılıyor.

sudo systemctl restart mariadb

ssl_passphrase belgelere göre MariaDB 12.0 ile eklenmiştir ve parolanın doğrudan (pass:), bir ortam değişkeninden (env:) ya da bir dosyanın ilk satırından (file:) okunmasını sağlar. Ayarlandığında SHOW VARIABLES yalnızca kullanılan biçimi gösterir, parolanın kendisini göstermez. Bu sayede özel anahtarı parolasız saklamak zorunda kalmazsınız.

Protokol sürümünü sınırlamak

tls_version virgülle ayrılmış ve boşluk içermeyen bir sürüm listesi alır; listede olmayan sürümlere izin verilmez. Belgelere göre 10.6.16, 10.11.6 ve 11.0.4'ten itibaren varsayılan değer TLSv1.2,TLSv1.3'tür. Değişken dinamik değildir, yani değiştirmek için yeniden başlatma gerekir. Belgeler PCI DSS v3.2'nin en az TLSv1.2 önerdiğini de not eder.

[mariadb]
tls_version = TLSv1.2,TLSv1.3

Sertifikayı yeniden başlatmadan yenilemek

ssl_cert ve diğer TLS değişkenleri dinamik değildir; değerlerini değiştirmek için sunucuyu yeniden başlatmanız gerekir. Ancak süresi dolmak üzere olan bir sertifikayı aynı dosya yoluna yenisiyle değiştirdiyseniz FLUSH SSL bu dosyaları yeniden yükleyerek TLS bağlamını sunucuyu durdurmadan yeniler. Belgelere göre yeniden okunan dosyalar ssl_cert, ssl_key, ssl_ca, ssl_capath, ssl_crl ve ssl_crlpath ile tanımlananlardır.

FLUSH SSL;

İstemci tarafı: tek yönlü ve çift yönlü TLS

Belgeler iki kullanım biçimini ayırır. Tek yönlü TLS'te yalnızca sunucu sertifika ve özel anahtar sunar; bağlantı her iki yönde şifrelenir ama sertifikayla yalnızca sunucunun kimliği doğrulanır. MariaDB 11.4 ve Connector/C 3.4 ile bu kip varsayılandır: yerel olmayan tüm bağlantılarda TLS otomatik açılır ve doğrulanmış bir sunucu sertifikası istenir. Kendi CA'nızla doğrulama yapmak isterseniz istemcinin seçenek grubuna şunları yazarsınız:

[client-mariadb]
ssl_ca = /etc/my.cnf.d/certificates/ca.pem
ssl-verify-server-cert

Aynı ayarlar komut satırından da verilebilir:

mariadb -u myuser -p -h myserver.mydomain.com --ssl-ca=/etc/my.cnf.d/certificates/ca.pem --ssl-verify-server-cert

Sunucu sertifikası doğrulanırken istemci, sertifikanın Subject alanındaki Common Name (CN) değerini sunucunun host adı ve IP adresiyle karşılaştırır; sertifikada Subject Alternative Name alanları varsa ve kullanılan TLS kütüphanesi destekliyorsa onlar da kontrol edilir. Belgelere göre MariaDB 11.3 öncesinde sunucu sertifikası doğrulaması varsayılan olarak kapalıydı. disable-ssl-verify-server-cert ile doğrulamayı kapatmak mümkündür, ancak bağlantı şifreli olsa bile ortadaki adam saldırısına açık hâle gelir.

Çift yönlü TLS'te istemci de kendi sertifikasını ve anahtarını sunar ve sunucu istemciyi sertifikayla doğrulayabilir. Belgelere göre bir hesapta REQUIRE X509, REQUIRE SUBJECT ya da REQUIRE ISSUER varsa çift yönlü TLS zorunludur:

[client-mariadb]
ssl_cert = /etc/my.cnf.d/certificates/client-cert.pem
ssl_key = /etc/my.cnf.d/certificates/client-key.pem
ssl_ca = /etc/my.cnf.d/certificates/ca.pem
ssl-verify-server-cert

Hesap bazında TLS zorunluluğu

TLS'i yalnızca belirli hesaplar için zorunlu kılabilirsiniz; bu kısıtlamalar CREATE USER, ALTER USER ya da GRANT ile verilir. REQUIRE sözcüğü bir kez yazılır, seçenekler arasında AND isteğe bağlıdır.

ALTER USER 'alice'@'%' 
   REQUIRE SSL;

Belgeler REQUIRE SSL ve REQUIRE X509 seçeneklerinin yalnızca bağlantının şifreli olduğunu ve istemcinin güvenilir bir CA'nın imzaladığı bir sertifika sunduğunu garanti ettiğini, hangi istemcinin bağlandığını belirlemediğini vurgular. Hesabı belirli bir sertifika kimliğine bağlamak için REQUIRE SUBJECT kullanılır; birden çok CA'ya güveniyorsanız REQUIRE ISSUER ile imzalayanı da sabitleyin. Aynı kullanıcı adı için farklı hostlarda farklı kurallar tanımlanabilir:

CREATE USER 'alice'@'localhost' 
   REQUIRE NONE;

CREATE USER 'alice'@'%'
   REQUIRE SUBJECT '/CN=alice/O=My Dom, Inc./C=US/ST=Oregon/L=Portland'
   AND ISSUER '/C=FI/ST=Somewhere/L=City/ O=Some Company/CN=Peter Parker/emailAddress=p.parker@marvel.com'
   AND CIPHER 'ECDHE-ECDSA-AES256-SHA384';

Subject karşılaştırmasının inceliği

Belgelere göre Subject karşılaştırması bayt bayt yapılır: büyük küçük harf ve alanların sırası önemlidir, kullanılan TLS kütüphanesi de sonucu etkiler (OpenSSL 3.0 ve sonrası alan içindeki / ve + karakterlerini ters eğik çizgiyle kaçışlar, OpenSSL 1.1 ve WolfSSL kaçışlamaz). Bu yüzden değeri elle yazmak yerine sunucunun biçiminde yazdırıp kopyalamanız önerilir. Eşleşme olmazsa sunucu iki dizeyi de hata günlüğüne yazar.

openssl x509 -noout -subject -nameopt compat -in alice-cert.pem

Sunucu genelinde güvenli taşıma

Tüm bağlantılar için güvenli taşıma istiyorsanız require_secure_transport değişkeni vardır. Belgelere göre açıldığında güvensiz taşımayla gelen bağlantılar reddedilir; güvenli sayılanlar TLS, Unix soketleri ve named pipe'lardır. Varsayılanı OFF'tur, dinamiktir ve hesap bazındaki gereksinimler bu ayarın önüne geçer. Yerel Unix soket bağlantıları etkilenmediği için sudo mariadb ile yönetim girişi çalışmaya devam eder.

Kuantum sonrası kriptografi notu

Belgelerde ayrı bir sayfa kuantum sonrası kriptografiye ayrılmıştır. Buna göre MariaDB, OpenSSL 3.5 ya da sonrasıyla bağlandığında TLS 1.3 anahtar değişiminde ML-KEM'i otomatik olarak müzakere eder ve ek bir sunucu değişkeni gerektirmez. Geçiş döneminde klasik X25519 ile ML-KEM birlikte kullanılır (hibrit kip) ve el sıkışmada X25519MLKEM768 grubu görülür; ML-KEM desteklemeyen istemciler klasik anahtar değişimiyle bağlanmaya devam eder. Sunucunuzun hangi TLS kütüphanesini kullandığını version_ssl_library değişkeni gösterir.

Replikasyon trafiğini şifrelemek için ayrıca birincil ve replika ayarları gerekir; bu konu replikasyon yazısında ele alınıyor.

Sık yapılan hatalar

• Sunucu sertifika doğrulamasını kapatmak: disable-ssl-verify-server-cert ya da --skip-ssl-verify-server-cert bağlantıyı ortadaki adam saldırısına açar.
• Göreli yol kullanmak: ssl_ca, ssl_capath, ssl_crl mutlak yol ister.
• Paketle gelen yapılandırma dosyasını düzenlemek: Belgeler z- ile başlayan ayrı bir dosya önerir.
• REQUIRE SSL ile istemci kimliğini doğruladığını sanmak: Yalnızca şifrelemeyi zorunlu kılar; kimlik için REQUIRE SUBJECT ve REQUIRE ISSUER gerekir.
• Subject değerini elle yazmak: Bayt bayt karşılaştırıldığı için harf ya da sıra farkı eşleşmeyi bozar.
• Sertifika değişikliği için sunucuyu gereksiz yere durdurmak: Aynı yollardaki dosyalar FLUSH SSL ile yeniden yüklenir.
• PAM ya da GSSAPI ile sıfır yapılandırmalı TLS'e güvenmek: Bu eklentilerle CA tabanlı doğrulama gerekir.

Sık Sorulan Sorular

MariaDB 12.3 kullanıyorum, TLS için bir şey yapmam gerekir mi?

Sunucu ve istemci 11.4 ya da üstüyse ve hesap mysql_native_password, ed25519 ya da parsec kullanıyorsa, yerel olmayan bağlantılar belgelere göre varsayılan olarak şifrelenir ve doğrulanır. Eski istemciler, PAM gibi eklentiler ya da istemci sertifikası gereken durumlar için kendi sertifikalarınızı yapılandırın.

Bağlantımın şifreli olduğunu nasıl anlarım?

Bağlıyken SHOW SESSION STATUS LIKE 'Ssl_version'; çalıştırın. Bir TLS sürümü görüyorsanız bağlantı şifrelidir; değer boşsa şifreleme yoktur.

Sertifikamın süresi doluyor, sunucuyu yeniden başlatmam gerekir mi?

Yeni sertifikayı ve anahtarı aynı dosya yollarına koyup FLUSH SSL; çalıştırmanız yeterlidir. Dosya yollarını değiştirmek istiyorsanız değişkenler dinamik olmadığı için yeniden başlatma gerekir.

TLS açtım; güvenlik duvarı ayarı yine de gerekli mi?

Evet. TLS trafiği şifreler ama portun kimlere açık olduğunu sınırlamaz. Port erişimini yalnızca gerekli adreslere açmak için UFW güvenlik duvarı rehberine bakabilirsiniz.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: MariaDB öğrenme rehberi · MariaDB uzaktan bağlantı · MariaDB kimlik doğrulama · MariaDB my.cnf · MariaDB replikasyon · MariaDB GRANT ve REVOKE · Ubuntu UFW rehberi