ჰედერები როგორც ჩანთები
HTTP ლოგირების ფრეიმვორკები მოთხოვნის ჰედერებს განიხილავენ როგორც გასაღები-მნიშვნელობის წყვილების ჩანთას. ლოგირების API აჩვენებს მთელ ჩანთას. ოპერატორები ჩართავენ ჰედერების ლოგირებას გამართვისთვის: როდესაც მოთხოვნა ვერ ხერხდება, ჰედერები მოგვითხრობენ ისტორიას. არ არსებობს ჩაშენებული უარყოფის სია. არ არსებობს კრედენშალების ფილტრაცია დოკუმენტაციაში. სრული ჰედერები დისკზე.
ტიპურ მოთხოვნაში კრედენშალების ჰედერები:
- Authorization: Bearer eyJhbGciOiJIUzI1NiJ9... (JWT ან OAuth ტოკენი)
- Cookie: session=abc123; auth=xyz789
- X-API-Key: sk-live-abc123...
- X-Auth-Token: ghp_abc123... (GitHub პერსონალური წვდომის ტოკენის ნიმუში)
ეს მნიშვნელობები ავთენტიფიცირებს მოთხოვნას. თუ ისინი ჩაიწერება ლოგ ფაილში, ისინი ავთენტიფიცირებს ნებისმიერ მოთხოვნას.
სერთიფიკატების მილსადენი
ლოგ ფაილში ჩაწერილი სერთიფიკატი არ რჩება ერთ ადგილას. ის მოგზაურობს:
1. ვებ სერვერი წერს /var/log/nginx/access.log-ში
2. ლოგების როტაციის აგენტი (logrotate) აკოპირებს /var/log/nginx/access.log.1-ში
3. ლოგების გადამზიდავი (Fluentd, Filebeat, Logstash) კითხულობს და აგზავნის აგრეგატორში
4. ლოგების აგრეგატორი (Elasticsearch, Splunk, Datadog) ინდექსირებს და ინახავს
5. ინახება 30-90 დღის განმავლობაში ნაგულისხმევი პოლიტიკის მიხედვით
სერთიფიკატი ერთდროულად ყველა ხუთივე ადგილას არსებობს. სესიის ტოკენის გაუქმება არ აშორებს სერთიფიკატს ლოგების აგრეგატორიდან. ის რჩება საძებნელი, ექსპორტირებადი და ხელმისაწვდომი ყველასთვის, ვისაც აქვს ლოგებზე წვდომა, სრული შენახვის პერიოდის განმავლობაში.
ექსპოზიციის ფანჯარა
სერთიფიკატის ექსპოზიციის ფანჯარა მეხსიერებაში: max(სესიის ხანგრძლივობა, პროცესის სიცოცხლე). სესია: საათებიდან დღეებამდე. პროცესი: საათებიდან კვირებამდე.
სერთიფიკატის ექსპოზიციის ფანჯარა ლოგში: max(სესიის ხანგრძლივობა, ლოგის შენახვის ვადა). სესია: საათებიდან დღეებამდე. შენახვა: 30-90 დღე.
მეხსიერებიდან მოპარული სერთიფიკატი მოითხოვდა თავდამსხმელის ყოფნას სესიის ფანჯრის განმავლობაში. ლოგიდან მოპარული სერთიფიკატი მოითხოვს მხოლოდ ლოგების აგრეგატორზე წვდომას, რაც რეტროაქტიულად ხელმისაწვდომია სრული შენახვის პერიოდის განმავლობაში.
MOAD-0003 vs MOAD-0004
MOAD-0003 (გაჟონილი კონტექსტი): მეხსიერებაში არსებული სერთიფიკატი გაჟონავს არასწორ მოთხოვნის დამმუშავებელს. ხელმისაწვდომია მხოლოდ პროცესის ფანჯარაში, თრედ პულის მეშვეობით. ეფემერული.
MOAD-0004 (ჩაწერილი საიდუმლო): დისკზე არსებული სერთიფიკატი რჩება ლოგების როტაციის, გადაზიდვისა და აგრეგაციის შემდეგაც. ხელმისაწვდომია რეტროაქტიულად, ყველასთვის, ვისაც ლოგებზე წვდომა აქვს, 30-90 დღის განმავლობაში. მუდმივი.
სტრუქტურული განსხვავება: ეფემერული vs მუდმივი. გამოსწორება მოქმედებს სხვა ფენაზე.
ეფემერული vs მუდმივი
ეფემერული/მუდმივი განსხვავება განსაზღვრავს რისკის ზედაპირს, გამოსწორების ფენას და ინციდენტზე რეაგირების მოთხოვნებს.
Credential Denylist at the Serialization Layer
გამოსწორება: სერთიფიკატების უარყოფითი სია სერიალიზაციის ფენაზე. სანამ რომელიმე header-ის მნიშვნელობა ლოგის გამომავალს მიაღწევს, შეამოწმეთ header-ის სახელი უარყოფითი სიის მიხედვით. შეცვალეთ მნიშვნელობა [REDACTED]-ით.
CREDENTIAL_HEADERS = {
'authorization',
'cookie',
'x-api-key',
'x-auth-token',
'x-csrf-token',
'proxy-authorization',
}
def sanitize_headers(headers: dict) -> dict:
return {
k: '[REDACTED]' if k.lower() in CREDENTIAL_HEADERS else v
for k, v in headers.items()
}Denylist უნდა იყოს სერიალიზაციის ფენაზე და არა ლოგის მოთხოვნის ფენაზე. ლოგის მოთხოვნის რედაქცია: გამოიყენება მას შემდეგ, რაც კრედენციალი დისკზე მოხვდება; ნედლი მნიშვნელობა მაინც არსებობს, უბრალოდ დამალულია ჩვენებისგან. სერიალიზაციის ფენის რედაქცია: კრედენციალი არასოდეს აღწევს დისკს. ნედლი მნიშვნელობა არასოდეს შედის ლოგის ფაილში, ლოგის გამგზავნელში ან ლოგის აგრეგატორში.
Denylist-ის ტესტირება
სამი ტესტის ნიმუში:
- დადებითი: მოთხოვნა Authorization: Bearer token123 აწარმოებს ლოგის ჩანაწერს Authorization: [REDACTED]
- უარყოფითი: Content-Type: application/json ტიპის მოთხოვნა ქმნის ლოგის ჩანაწერს მნიშვნელობის შენარჩუნებით
- რეგისტრისგან დამოუკიდებელი: AUTHORIZATION: Bearer token123 ასევე იწვევს [REDACTED]-ის გამოჩენას (HTTP header-ების სახელები რეგისტრისგან დამოუკიდებელია)
Denylist-ს სჭირდება მოვლა: ახალი სერთიფიკატის header-ების შაბლონები (მაგ. custom X-Service-Auth headers) საჭიროებს ცალსახა დამატებას. გამოსწორება სტრუქტურულია, მაგრამ თვითშენარჩუნებადი არ არის.
Denylist-ის გამოყენება
გუნდი აკონფიგურირებს Nginx-ის წვდომის ლოგის ფორმატს, რათა მოიცავდეს ყველა მოთხოვნის header-ს წარმოების ინციდენტის გამართვის მიზნით. კონფიგურაცია:
log_format debug_format '$remote_addr - $request - $http_authorization - $http_cookie';
access_log /var/log/nginx/debug.log debug_format;ისინი აგვარებენ ინციდენტს და აპირებენ debug კონფიგურაციის წაშლას, მაგრამ ცვლილება არ აღწევს production-ში შემდეგი დეპლოიმენტის ციკლამდე (7 დღის შემდეგ).