დაშიფვრა MySQL-ში: Keystore

კურსზე ახალი ჩარიცხვის დაწყების მოლოდინში "Მონაცემთა ბაზა" ჩვენ მოვამზადეთ თქვენთვის სასარგებლო სტატიის თარგმანი.

მონაცემთა გამჭვირვალე დაშიფვრა (TDE) გამოჩნდა Percona სერვერი MySQL-სთვის და MySQL საკმაოდ დიდი ხნის განმავლობაში. მაგრამ გიფიქრიათ ოდესმე იმაზე, თუ როგორ მუშაობს ის ქუდის ქვეშ და რა გავლენა შეიძლება ჰქონდეს TDE-ს თქვენს სერვერზე? სტატიების ამ სერიაში ჩვენ გადავხედავთ, თუ როგორ მუშაობს TDE შიგნით. დავიწყოთ გასაღების შენახვით, რადგან ეს საჭიროა ნებისმიერი დაშიფვრის მუშაობისთვის. შემდეგ ჩვენ უფრო დეტალურად განვიხილავთ, თუ როგორ მუშაობს დაშიფვრა Percona Server-ში MySQL/MySQL-ისთვის და რა დამატებითი ფუნქციები აქვს Percona Server-ს MySQL-ისთვის.

MySQL Keyring

Keyring არის დანამატები, რომლებიც სერვერს საშუალებას აძლევს მოითხოვოს, შექმნას და წაშალოს გასაღებები ადგილობრივ ფაილში (keyring_file) ან დისტანციურ სერვერზე (როგორიცაა HashiCorp Vault). გასაღებები ყოველთვის ინახება ადგილობრივად, რათა დააჩქაროს მათი მოძიება.

დანამატები შეიძლება დაიყოს ორ კატეგორიად:

• ადგილობრივი საცავი. მაგალითად, ლოკალური ფაილი (ამას ჩვენ ვუწოდებთ ფაილზე დაფუძნებულ გასაღებს).
• დისტანციური შენახვა. მაგალითად, Vault Server (ამას სერვერზე დაფუძნებულ გასაღებს ვუწოდებთ).

ეს განცალკევება მნიშვნელოვანია, რადგან მეხსიერების სხვადასხვა ტიპები ოდნავ განსხვავებულად იქცევიან, არა მხოლოდ გასაღებების შენახვისა და მიღებისას, არამედ მათი გაშვებისას.

ფაილის შენახვის გამოყენებისას, გაშვებისას, მეხსიერების მთელი შინაარსი იტვირთება ქეშში: გასაღების ID, გასაღების მომხმარებელი, გასაღების ტიპი და თავად გასაღები.

სერვერის მაღაზიის შემთხვევაში (როგორიცაა Vault Server), გაშვებისას იტვირთება მხოლოდ გასაღების id და გასაღების მომხმარებელი, ამიტომ ყველა გასაღების მიღება არ ანელებს გაშვებას. გასაღებები ზარმაცი იტვირთება. ანუ, გასაღები თავად იტვირთება Vault-დან მხოლოდ მაშინ, როდესაც ის რეალურად საჭიროა. ჩამოტვირთვის შემდეგ, გასაღები ინახება მეხსიერებაში, რათა მომავალში არ დასჭირდეს მასზე წვდომა Vault სერვერთან TLS კავშირებით. შემდეგი, მოდით შევხედოთ რა ინფორმაციას შეიცავს გასაღების მაღაზიაში.

ძირითადი ინფორმაცია შეიცავს შემდეგს:

• გასაღების ID - გასაღების იდენტიფიკატორი, მაგალითად:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• გასაღების ტიპი — გასაღების ტიპი გამოყენებული დაშიფვრის ალგორითმის საფუძველზე, შესაძლო მნიშვნელობები: „AES“, „RSA“ ან „DSA“.
• გასაღების სიგრძე — გასაღების სიგრძე ბაიტებში, AES: 16, 24 ან 32, RSA 128, 256, 512 და DSA 128, 256 ან 384.
• მომხმარებელი - გასაღების მფლობელი. თუ გასაღები არის სისტემა, მაგალითად, Master Key, მაშინ ეს ველი ცარიელია. თუ გასაღები იქმნება keyring_udf-ის გამოყენებით, მაშინ ეს ველი განსაზღვრავს გასაღების მფლობელს.
• თავად გასაღები

გასაღები ცალსახად იდენტიფიცირებულია წყვილით: key_id, მომხმარებელი.

ასევე არსებობს განსხვავებები გასაღებების შენახვასა და წაშლაში.

ფაილის შენახვა უფრო სწრაფია. შეიძლება იფიქროთ, რომ გასაღების მაღაზია უბრალოდ ერთხელ წერს ფაილის გასაღებს, მაგრამ არა, აქ უფრო მეტი ხდება. როდესაც ხდება ფაილის შენახვის მოდიფიკაცია, პირველად იქმნება მთელი შინაარსის სარეზერვო ასლი. ვთქვათ, ფაილს ერქვა my_biggest_secrets, მაშინ სარეზერვო ასლი იქნება my_biggest_secrets.backup. შემდეგი, ქეში იცვლება (გასაღებები ემატება ან წაიშლება) და თუ ყველაფერი წარმატებით დასრულდა, ქეში გადაკეთდება ფაილზე. იშვიათ შემთხვევებში, როგორიცაა სერვერის უკმარისობა, შეგიძლიათ ნახოთ ეს სარეზერვო ფაილი. სარეზერვო ფაილი წაიშლება კლავიშების ჩატვირთვის შემდეგ (ჩვეულებრივ, სერვერის გადატვირთვის შემდეგ).

სერვერის საცავში გასაღების შენახვის ან წაშლისას, საცავი უნდა დაუკავშირდეს MySQL სერვერს ბრძანებებით "გაგზავნა გასაღები" / "მოითხოვე გასაღების წაშლა".

მოდით დავუბრუნდეთ სერვერის გაშვების სიჩქარეს. გარდა იმისა, რომ გაშვების სიჩქარეზე გავლენას ახდენს თავად სარდაფი, ასევე ჩნდება საკითხი, თუ რამდენი კლავიშის ამოღება გჭირდებათ გაშვებისას. რა თქმა უნდა, ეს განსაკუთრებით მნიშვნელოვანია სერვერის შენახვისთვის. გაშვებისას სერვერი ამოწმებს რომელი გასაღებია საჭირო დაშიფრული ცხრილებისთვის/მაგიდის სივრცისთვის და ითხოვს გასაღებს მეხსიერებიდან. "სუფთა" სერვერზე Master Key დაშიფვრით, უნდა არსებობდეს ერთი ძირითადი გასაღები, რომელიც უნდა იყოს აღებული საცავიდან. თუმცა, შეიძლება საჭირო გახდეს გასაღებების უფრო დიდი რაოდენობა, მაგალითად, როდესაც სარეზერვო სერვერი აღადგენს სარეზერვო ასლს ძირითადი სერვერიდან. ასეთ შემთხვევებში უზრუნველყოფილი უნდა იყოს ძირითადი გასაღების როტაცია. ეს უფრო დეტალურად იქნება განხილული მომავალ სტატიებში, თუმცა აქვე მინდა აღვნიშნო, რომ სერვერს, რომელიც იყენებს რამდენიმე მთავარ კლავიშს, შეიძლება ცოტა მეტი დრო დასჭირდეს გაშვებას, განსაკუთრებით სერვერის მხარეს გასაღებების შენახვისას.

ახლა მოდით ვისაუბროთ ცოტა მეტი keyring_file-ზე. როდესაც მე ვამუშავებდი keyring_file, მე ასევე მაინტერესებდა, როგორ შემემოწმებინა keyring_file ცვლილებები სერვერის მუშაობისას. 5.7-ში შემოწმება განხორციელდა ფაილური სტატისტიკის საფუძველზე, რაც არ იყო იდეალური გადაწყვეტა და 8.0-ში იგი შეიცვალა SHA256 საკონტროლო ჯამით.

პირველად გაშვებისას keyring_file, გამოითვლება ფაილის სტატისტიკა და გამშვები ჯამი, რომლებიც ახსოვს სერვერს და ცვლილებები გამოიყენება მხოლოდ იმ შემთხვევაში, თუ ისინი ემთხვევა. როდესაც ფაილი იცვლება, საკონტროლო ჯამი განახლდება.

ჩვენ უკვე განვიხილეთ მრავალი კითხვა გასაღების სარდაფებთან დაკავშირებით. თუმცა, არის კიდევ ერთი მნიშვნელოვანი თემა, რომელიც ხშირად დავიწყებული ან არასწორად არის გაგებული: გასაღებების გაზიარება სერვერებზე.

Რას ვგულისხმობ? თითოეულ სერვერს (მაგალითად, Percona სერვერს) კლასტერში უნდა ჰქონდეს ცალკე მდებარეობა Vault სერვერზე, რომელშიც Percona სერვერმა უნდა შეინახოს თავისი გასაღებები. საცავში შენახული თითოეული ძირითადი გასაღები შეიცავს Percona სერვერის GUID-ს მის იდენტიფიკატორში. Რატომ არის ეს მნიშვნელოვანი? წარმოიდგინეთ, რომ თქვენ გაქვთ მხოლოდ ერთი Vault სერვერი და ყველა Percona სერვერი კლასტერში იყენებს ამ ცალკეულ Vault სერვერს. პრობლემა აშკარად ჩანს. თუ Percona-ს ყველა სერვერი გამოიყენებდა მთავარ კლავიშს უნიკალური იდენტიფიკატორების გარეშე, როგორიცაა id = 1, id = 2 და ა.შ., მაშინ კლასტერში ყველა სერვერი გამოიყენებდა იმავე მთავარ კლავიშს. რასაც GUID გთავაზობთ არის განსხვავება სერვერებს შორის. რატომ უნდა ვისაუბროთ სერვერებს შორის გასაღებების გაზიარებაზე, თუ უნიკალური GUID უკვე არსებობს? არის კიდევ ერთი მოდული - keyring_udf. ამ მოდულით, თქვენს სერვერის მომხმარებელს შეუძლია შეინახოს გასაღებები Vault სერვერზე. პრობლემა ჩნდება, როდესაც მომხმარებელი ქმნის გასაღების სერვერზე1, მაგალითად, და შემდეგ ცდილობს შექმნას გასაღები იგივე ID-ით სერვერ2-ზე, მაგალითად:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

მოიცადე. ორივე სერვერი იყენებს ერთსა და იმავე Vault Server-ს, არ უნდა მოხდეს keyring_key_store ფუნქცია სერვერ2-ზე? საინტერესოა, რომ თუ ცდილობთ იგივეს გაკეთებას ერთ სერვერზე, მიიღებთ შეცდომას:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

მართალია, ROB_1 უკვე არსებობს.

ჯერ მეორე მაგალითზე ვიმსჯელოთ. როგორც ადრე ვთქვით, keyring_vault ან სხვა გასაღების დანამატი ინახავს ყველა გასაღების ID-ს მეხსიერებაში. ასე რომ, ახალი გასაღების შექმნის შემდეგ ROB_1 ემატება server1-ს და ამ გასაღების Vault-ში გაგზავნის გარდა, გასაღებიც ემატება ქეშს. ახლა, როდესაც მეორედ ვცდილობთ იგივე გასაღების დამატებას, keyring_vault ამოწმებს არის თუ არა გასაღები ქეშში და უშვებს შეცდომას.

პირველ შემთხვევაში სიტუაცია განსხვავებულია. Server1-სა და Server2-ს აქვთ ცალკე ქეში. ROB_1-ის დამატების შემდეგ გასაღების ქეში სერვერზე1 და Vault სერვერზე, გასაღების ქეში სერვერ2-ზე სინქრონიზებულია. სერვერ2-ზე ქეშში არ არის ROB_1 გასაღები. ამრიგად, ROB_1 გასაღები იწერება keyring_key_store-ზე და Vault სერვერზე, რომელიც რეალურად გადაწერს (!) წინა მნიშვნელობას. ახლა Vault სერვერზე ROB_1 გასაღები არის 543210987654321. საინტერესოა, რომ Vault სერვერი არ ბლოკავს ასეთ ქმედებებს და ადვილად გადაწერს ძველ მნიშვნელობას.

ახლა ჩვენ ვხედავთ, რატომ შეიძლება იყოს მნიშვნელოვანი სერვერის დაყოფა Vault-ში - როდესაც იყენებთ keyring_udf-ს და გსურთ შეინახოთ გასაღებები Vault-ში. როგორ მივაღწიოთ ამ განცალკევებას Vault სერვერზე?

Vault-ში დაყოფის ორი გზა არსებობს. თქვენ შეგიძლიათ შექმნათ სხვადასხვა სამონტაჟო წერტილები თითოეული სერვერისთვის, ან გამოიყენოთ სხვადასხვა ბილიკები იმავე სამონტაჟო წერტილში. ეს საუკეთესოდ ილუსტრირებულია მაგალითებით. მოდით, პირველ რიგში გადავხედოთ დამაგრების ცალკეულ წერტილებს:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)

--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)

აქ ხედავთ, რომ server1 და server2 იყენებენ სხვადასხვა სამონტაჟო წერტილებს. ბილიკების გაყოფისას, კონფიგურაცია ასე გამოიყურება:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)

ამ შემთხვევაში, ორივე სერვერი იყენებს იმავე სამონტაჟო წერტილს "mount_point", მაგრამ სხვადასხვა ბილიკებს. როდესაც თქვენ შექმნით პირველ საიდუმლოს server1-ზე ამ გზის გამოყენებით, Vault სერვერი ავტომატურად ქმნის "server1" დირექტორიას. სერვერ2სთვის ყველაფერი მსგავსია. როდესაც თქვენ წაშლით ბოლო საიდუმლოს mount_point/server1-ში ან mount_point/server2-ში, Vault სერვერი ასევე წაშლის ამ კატალოგებს. თუ იყენებთ ბილიკების განცალკევებას, თქვენ უნდა შექმნათ მხოლოდ ერთი სამონტაჟო წერტილი და შეცვალოთ კონფიგურაციის ფაილები ისე, რომ სერვერებმა გამოიყენონ ცალკე ბილიკები. სამონტაჟო წერტილი შეიძლება შეიქმნას HTTP მოთხოვნის გამოყენებით. CURL-ის გამოყენებით ეს შეიძლება გაკეთდეს ასე:

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

ყველა ველი (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) შეესაბამება კონფიგურაციის ფაილის პარამეტრებს. რა თქმა უნდა, შეგიძლიათ გამოიყენოთ Vault უტილიტები იგივეს გასაკეთებლად. მაგრამ უფრო ადვილია სამონტაჟო წერტილის შექმნის ავტომატიზაცია. ვიმედოვნებ, რომ ეს ინფორმაცია თქვენთვის სასარგებლო იქნება და ამ სერიის შემდეგ სტატიებში შეგხვდებით.

Წაიკითხე მეტი:

• Sysbench და შემთხვევითი ცვლადების განაწილება

წყარო: www.habr.com