დაგეგმილი დავალება თუ ადამიანის შესვლა: რომელი იდენტობა უნდა დაინახოს API-მ?

დაგეგმილი დავალება და შესვლის მოთხოვნასთან მდგომი ადამიანი ერთსა და იმავე API-ს იძახებენ სხვადასხვა სერტიფიკატით, სხვადასხვა სიცოცხლის ხანგრძლივობით და სხვადასხვა მფლობელით. დავალებას სჭირდება ქსელის გზა, აპლიკაციის იდენტობა და ნებართვების ნაკრები; ადამიანს სჭირდება შესვლა, მეორე ფაქტორი და სესია. ორივეს შერევა ქმნის ავტომატიზაციას, რომელიც ტყდება ყოველ ჯერზე, როცა ადამიანის პაროლი იცვლება, ან მრავალფაქტორიან პოლიტიკას, რომელიც ზუსტად იმდენადაა შესუსტებული, რომ cron დავალება ცოცხალი დარჩეს.

სამი კარიბჭე, რომლებიც ერთს ჰგავს

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

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

ინტერაქტიული გზა ცუდი შაბლონია ავტომატიზაციისთვის

ადამიანის შესვლის სკრიპტად ქცევა მაცდურია, რადგან ერთხელ მუშაობს. სკრიპტი ინახავს პაროლს, შესაძლოა ერთჯერადი პაროლის თესლს, და შემდეგ დამოკიდებულია გამოწვევაზე, რომელიც ადამიანის მოთხოვნისთვისაა შექმნილი. OAuth-ის უსაფრთხოების მიმდინარე საუკეთესო პრაქტიკა, RFC 9700, კრძალავს resource-owner-password-credentials გრანტს და ხსნის, რატომ ჯდება ის ცუდად ორფაქტორიან და მრავალსაფეხურიან ავთენტიფიკაციასთან.

მხარდაჭერილი ალტერნატივა ჩვეულებრივ კონფიდენციალური კლიენტის ნაკადია, სადაც ავტორიზაციის სერვერი ავთენტიფიცირებს აპლიკაციას და გასცემს ტოკენს. RFC 6749-ის 4.4 ნაწილის client-credentials გრანტი ერთი მაგალითია. მისი არსებობა არ ნიშნავს, რომ ყველა API მას იღებს, ან რომ მომხმარებლის მიერ დელეგირებული დავალება მისით ჩანაცვლდება, რადგან ეს სერვისის მფლობელის კითხვებია. ჰკითხეთ, რომელ უზედამხედველო მოდელს უჭერს მხარს სერვისი, სანამ კოდს დაწერთ.

სად არის VPN ჯერ კიდევ ადგილზე

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

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

შეადარეთ ორი დიზაინი პატიოსნად

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

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

რა უნდა გადამოწმდეს გადაცემამდე

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

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

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