MySQL VPN-ის გავლით: გადაამოწმეთ სერვერი და არა მხოლოდ დაშიფვრა
არასწორ ჰოსტზე დაშიფვრა მაინც არასწორია. შეადარეთ ssl-mode-ის მნიშვნელობები, შემდეგ გაუშვით კავშირი, რომელიც ასახელებს განზრახულ სერვერს და ამას ამტკიცებს.
თქვენ ინახავთ კავშირს 10.20.4.15-ზე, VPN ითიშება, და კლიენტი მაინც უკავშირდება. ეს კარგი ამბავი არ არის. კერძო მისამართი არის ადგილი ნებისმიერი იმ მარშრუტიზაციის კონტექსტის შიგნით, რომელშიც ხართ, და ბევრი ქსელი იყენებს იმავე დიაპაზონებს. კლიენტმა მიაღწია MySQL სერვერს, უბრალოდ შესაძლოა არა თქვენსას.
გასწორებას ორი ნახევარი აქვს და მათგან მხოლოდ ერთი ეხება ქსელს. შეინახეთ კავშირი განზრახულ გზაზე და აიძულეთ კლიენტი დაადასტუროს სერვერი, რომელთანაც საუბრობს. პირველი ნახევარი ის ადგილია, სადაც VPN ეხმარება; მეორე ნახევარი უნდა დაკონფიგურდეს.
რაზეა დაშიფრული, ზუსტად?
TLS იცავს საუბარს შუაში მყოფი ნებისმიერისგან და არაფერს ამბობს იმაზე, თუ ვინ ამტკიცებს, რომ არის ბოლო წერტილი, თუ კლიენტი ამას არ ამოწმებს. სერტიფიკატი, რომელიც მოწმდება სანდო ორგანოს წინააღმდეგ, ამტკიცებს, რომ სერტიფიკატი ამ ორგანოსგან მოვიდა. ის არ ამტკიცებს, რომ სერტიფიკატი გაიცა იმ ჰოსტის სახელზე, რომელზეც გსურდათ მისვლა, და ეს სხვადასხვა კითხვებია.
ეს თეორიული ხარვეზი არ არის. Captive პორტალები, არასწორი VRF-ის შეცდომები და გადაფარვადი მისამართების გეგმები ყველა ქმნის სერვერს, რომელიც სრულიად მზადაა თქვენთან TLS-ის მოლაპარაკებისთვის. თუ კლიენტი მხოლოდ დაშიფვრას მოითხოვს, სესია კერძოა და არასწორი მონაცემთა ბაზისკენაა მიმართული.
ამიტომ შესაბამისი კითხვა არ არის, დაშიფრულია თუ არა კავშირი, არამედ ის, დაშიფრულია თუ არა იმ იდენტობისკენ, რომელიც განიზრახეთ. MySQL-ის კლიენტში ეს განსხვავება მთლიანად ssl-mode პარამეტრში ცხოვრობს.
ხუთი ssl-mode მნიშვნელობა პრაქტიკაში
არსებობს ხუთი მნიშვნელობა და მათგან მხოლოდ ერთი პასუხობს ამ სახელმძღვანელოს კითხვას. ცხრილი ჩამოთვლის, თუ რას უზრუნველყოფს თითოეული სინამდვილეში და არა იმას, რასაც მისი სახელი მიანიშნებს.
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
ამ სტატიის კითხვაზე მხოლოდ ბოლო სტრიქონი პასუხობს. PREFERRED თავისთავად აღსანიშნავია, რადგან კლიენტი, რომელიც ჩუმად ცვივა ღია ტექსტში, უარესია, ვიდრე უარმყოფელი: ფიქრობთ, რომ დაშიფვრა გაქვთ და პაკეტების ჩაწერა არ ეთანხმება.
კავშირი, რომლის გაშვებაც დღეს შეგიძლიათ
ქვემოთ მოცემული ბრძანება არის ფორმა, რომელიც უნდა გამოიყენოთ, ორი დროებითი ადგილით: დამტკიცებული მონაცემთა ბაზის სახელი და დამტკიცებული არხით მიღებული CA ფაილი. არცერთი მათგანი არ უნდა იქნას აღებული იმისგან, რასაც სერვერი შემოგთავაზებთ პირველ კონტაქტზე.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password მნიშვნელობის გარეშე ითხოვს შეყვანას, რაც საიდუმლოს პროცესების სიისა და თქვენი shell-ის ისტორიის გარეთ ინახავს. ეს პატარა ჩვევაა დიდი სარგებლით საერთო jump ჰოსტებზე, სადაც ბრძანების სტრიქონი სხვა მომხმარებლებისთვის ხილვადია.
როცა ეს ვერ ხერხდება, შეცდომის ტექსტი შემთხვევებს უკეთ განასხვავებს, ვიდრე ინტუიცია. CA-ს უკმარისობა ნიშნავს, რომ ჯაჭვი არ მოწმდება და უნდა ნახოთ, რომელმა CA-მა მოაწერა ხელი სერვერის სერტიფიკატს. ჰოსტის სახელის უკმარისობა ნიშნავს, რომ ჯაჭვი რიგზეა და სახელი არ ემთხვევა, რაც ჩვეულებრივ ნიშნავს, რომ სწორ სერვერს არასწორი სახელით დაუკავშირდით და არა არასწორ სერვერს.
მოთხოვნის გამოჩენა არ არის მტკიცებულება, რომ პაროლი უკვე გადაცემულია, და წარუმატებელი კავშირი არ ამტკიცებს, რომ კლიენტიდან არაფერი გავიდა. თუ წარსული მოვლენის რეკონსტრუქციას აკეთებთ, დაადგინეთ კლიენტი, მისი კონფიგურაცია, ავთენტიფიკაციის დანამატი და ის ეტაპი, რომელიც ვერ შესრულდა. ზემოქმედების შეფასება საბოლოო შეცდომის შეტყობინებიდან ვარაუდია.
როცა სახელი გვირაბიდან მოდის
ლოკალური პორტის გადამისამართება ამტვრევს იდენტობის შემოწმებას იმ გზით, რომელიც ხალხს აკვირვებს. თუ ლოკალურ პორტს გადაამისამართებთ მონაცემთა ბაზაზე და დაუკავშირდებით localhost-ს, კლიენტი სერტიფიკატს ამოწმებს localhost-ის წინააღმდეგ, და ამ სახელზე სერტიფიკატი არ გაცემულა. კავშირი შეიძლება სრულიად უსაფრთხო იყოს და შემოწმება მაინც ჩავარდეს, რაც ნიშნავს, რომ შემოწმება განზრახვისამებრ მუშაობს.
ორი პატიოსანი პასუხი არსებობს. მიეცით გადამისამართებულ ბოლო წერტილს სახელი, რომელიც loopback მისამართზე წყდება და სერვერის სერტიფიკატში ჩანს, ან გამოიყენეთ ჰოსტის სახელი თავიდან ბოლომდე, რომ კლიენტმა ნამდვილი იდენტობა გადაამოწმოს. პირველი მოსახერხებელია დეველოპერებისთვის და სერტიფიკატის სამუშაოს მოითხოვს; მეორეზე ფიქრი უფრო ადვილია და ხშირად ავტომატიზაციისთვის სწორი ნაგულისხმევია. შემოწმების გამორთვა იმისთვის, რომ გადამისამართება იმუშაოს, ის თვისება ისვრის, რომლის დამატებასაც ცდილობდით.
მიღება სამი პირობაა
ჩაწერეთ მიღების ტესტი სამ ცალკეულ დებულებად: კავშირმა გამოიყენა განზრახული მარშრუტი, დაშიფვრა მოითხოვებოდა და არა სასურველი იყო, და სერვერის იდენტობა სანდო მასალის წინააღმდეგ შემოწმდა. მწვანე VPN ხატულა არცერთ მათგანს არ ადგენს.
GUI კლიენტებისა და MariaDB-ისთვის შეამოწმეთ თავად გამყიდველის დოკუმენტაცია, ნაცვლად იმისა, რომ ჩათვალოთ დროშის მართლწერის გადატანა. MySQL-ის დოკუმენტაცია დაშიფრული კავშირების შესახებ მოიცავს რეჟიმებს შორის განსხვავებებს და CA-ის გავრცელების მოთხოვნას, და ეს არის ის ცნობარი, რომელიც უნდა შეამოწმოთ წარმოების კავშირის სტრიქონის შეცვლამდე.