Cassandra VPN-ის გავლით: ცალკე წვდომა კლიენტებისა და კვანძებისთვის

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

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

სამი აუდიტორია, სამი გადაწყვეტილება

სანამ რომელიმე წესს შეეხებით, დაადგინეთ, რა სჭირდება თითოეულ ჯგუფს სინამდვილეში. კლიენტებს სჭირდებათ კლიენტის მსმენელი და საკმარისი ინფორმაცია, რომ მიაღწიონ ყველა კვანძს, რომელიც მათ შეიძლება მიეცეს, თანატოლ კვანძებს სჭირდებათ ერთმანეთი კვანძთშორის პორტზე, ხოლო ოპერატორებს სჭირდებათ მართვის ინტერფეისი იმისთვის, რასაც runbook რეალურად ითხოვს. სამი სია, სამი აუდიტორია, ნდობის სამი დონე.

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

რა სჭირდებათ კლიენტებს, და მეტი არაფერი

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

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

შეინარჩუნეთ ასევე აპლიკაციის მონაცემთა ბაზის ავთენტიფიკაცია და როლის ნებართვები. საერთო თარგმნილი VPN მისამართი შეიძლება ბევრ მომხმარებელს ან სერვისს წარმოადგენდეს, ამიტომ ის არასდროს ანაცვლებს ცალკეულ მონაცემთა ბაზის იდენტობებს.

დაშიფრეთ ცალ-ცალკე კლიენტ-კვანძამდე და კვანძთშორისი

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

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

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

სერვერის იმ კონფიგურაციებზე, რომლებიც ნებას რთავს არასავალდებულო კლიენტის დაშიფვრას, TLS-ის მიღება შეიძლება თანაარსებობდეს დაუშიფრავი კავშირების მიღებასთან, ამიტომ წაიკითხეთ მოქმედი პოლიტიკა და არა განზრახვა. დაგეგმეთ სერთიფიკატების სახელები, ნდობის განაწილება და განახლება იმ საბოლოო წერტილებისთვის, რომლებთანაც თითოეული კლიენტი რეალურად უკავშირდება; ჰოსტის სახელის IP მისამართით ჩანაცვლება ცვლის კლიენტის იდენტობის შემოწმებას და არა მხოლოდ მის მარშრუტს.

მართვა საკუთარ ბილიკზე შეინარჩუნეთ

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

შეინარჩუნეთ თანხვედრაში მოქმედი ღრუბლოვანი წესები, ჰოსტის წესები და მსმენელის კონფიგურაცია. კერძო მსმენელი მაინც შეიძლება ღია იყოს გაუთვალისწინებელი გარდაქმნის ან პროქსის მეშვეობით, და ფართო საჯარო წესი შეიძლება ჩუმად იდგეს ვიწრო VPN წესის გვერდით, სანამ ვინმე ორივეს ერთდროულად აუდიტს ჩაატარებს.

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

რას ჰპირდება დიზაინი

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

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