შეუძლია VPN-ს ან პროქსის საავტორო უფლებებით დაცული შინაარსის კოპირება? სამი მოქმედება
პაკეტების გადაგზავნა, პასუხების ქეშირება და ხელახალი გამოქვეყნება საავტორო უფლებების ცალკეულ კითხვებს ბადებს. შეუსაბამეთ თქვენი სერვისის მოქმედება მისი მარეგულირებელი წესს.
პაკეტების გადაგზავნა, ქეშირება და ხელახალი გამოქვეყნება დაშბორდიდან ერთნაირად გამოიყურება და სრულიად სხვაგვარად იქცევა, როგორც კი უფლების კითხვა ჩნდება. სერვისი, რომელიც ბაიტებს მოძრაობს მომხმარებელსა და სერვერს შორის, ერთ მოქმედებას ასრულებს, ხოლო ის, რომელიც პასუხს ინახავს და შემდეგ ვიზიტორს აძლევს, სხვას. სხვისი მასალის საკუთარი სახელით გამოქვეყნება მესამეა, და მხოლოდ ის მესამე მოქმედებაა გავრცელება ჩვეულებრივი გაგებით.
დაადგინეთ, რომელს ამ სამიდან თქვენი სტეკი რეალურად ასრულებს, შემდეგ მიაბით მას შესაბამისი წესი. პროდუქტის ეტიკეტები აქ არაფერს წყვეტს, და გამოყენებული პროტოკოლიც არ არის საზომი.
სამი მოქმედება, რომელიც პროქსის ან VPN-ს შეუძლია შეასრულოს
კარიბჭე იღებს TCP ნაკადს, გადაწერს მისამართებს და ორივე მიმართულებით გადასცემს სეგმენტებს. დისკზე კავშირიდან არაფერი რჩება, და დატვირთვა კარიბჭისთვის გაუმჭვირვალე რჩება, თუ კლიენტი TLS-ს კარიბჭესთან არ შეათანხმებს და არა წყაროსთან.
ქეშის შუამავალი სხვაგვარად მუშაობს: აანალიზებს მოთხოვნას, ინახავს პასუხს თავის მიერ გამოთვლილი ან სათაურებიდან წაკითხული სიცოცხლის განმავლობაში, შემდეგ კი იმ შენახულ ობიექტს შემდგომ კლიენტებს უკრავს. ახლა რაღაც არსებობს მავთულის გარეთ, URL-ითა და ვალიდატორით ჩაკეტილი, და მისი შენახვა კონფიგურაციის არჩევანია და არა გვერდითი ეფექტი.
ხელახალი გამოქვეყნება ერთი ნაბიჯით შორს მიდის. მასალა თქვენ მიერ კონტროლირებულ ინფრასტრუქტურაზეა, თქვენ მიერ არჩეულ აუდიტორიაზე მიმართული, ხშირად რედაქტირების შემდეგ. პირველი ორი მოქმედება ტრანსპორტს აღწერს, ხოლო მესამე გავრცელებას.
| მოქმედება | რა რჩება შემდეგ | კითხვა, რომელიც შედეგს წყვეტს |
|---|---|---|
| ნაკადის ტარება | წამებით მოქმედი თარგმანის მდგომარეობა და ბუფერები | შუამავლის რომელი დებულება ფარავს გარდამავალ გადაცემას? |
| პასუხის შენახვა | ობიექტი და სიახლისა და ვალიდატორის მეტამონაცემები | იყო თუ არა შენახვა და გადაკვრა ნებადართული, და როდემდე? |
| ნაშრომის მიწოდება თქვენი URL-ის ქვეშ | გამოქვეყნებული ასლი, მიმართული ახალი აუდიტორიისკენ | რომელი ნებართვა ფარავს გავრცელებას იმ აუდიტორიაზე? |
სადაც გაშიფვრელი პროქსი ტრანსპორტს კოპირებად აქცევს
განსხვავება, რომელიც უმეტეს კამათს წყვეტს, არის ინახავს თუ არა ყუთი ოდესმე ღია ტექსტს. სუფთა გვირაბი, იქნება ეს WireGuard, OpenVPN tun მოწყობილობა თუ SSH -L გადაცემა, ბოლოებს შორის დაშიფრულ ტექსტს მოძრაობს და წაკითხვადი არაფერი ტოვებს. TLS-ს დამამთავრებელი პროქსი საპირისპიროს აკეთებს: ასრულებს ხელის ჩამორთმევას, ბუფერავს პასუხს მეხსიერებაში და შემდეგ ხელახლა შიფრავს ნაკადს კლიენტისკენ. ამ ოპერაციებს შორის ნაშრომი არსებობს იმ ფორმით, რომელსაც ოპერატორი შეამოწმებს და შეინახავს.
17 USC 106 გამრავლებასა და გავრცელებას განმარტავს გამომრიცხავ უფლებებს შორის, რომელთაგან თითოეული იმავე თავში დადგენილ შეზღუდვებს ექვემდებარება. მილიწამიანი ბუფერი შეიძლება უდავოდ მოთავსდეს შეზღუდვაში; შენახული, გადასაკრავი ობიექტის იქ მოთავსება გაცილებით რთულია. ხანგრძლივობა და მიზანი უფრო მეტს წონიან, ვიდრე ის ფაქტი, რომ მეხსიერებას საერთოდ შეეხნენ.
ამათგან არცერთი VPN-ს ლიცენზიად არ აქცევს და არცერთი ყოველ პროქსის დამრღვევად არ აქცევს. ტრანსპორტი ერთი ფაქტია რამდენიმეს შორის, და შესაფასებელი კითხვა იგივე რჩება: რომელი მოქმედება, ვის მასალაზე, რომელი ნებართვით.
ქეშის სათაურები პროტოკოლის ნებართვას აღწერენ, არა სამართლებრივ ნებართვას
HTTP ქეში პასუხის მეტამონაცემებიდან წყვეტს, რისი შენახვა შეუძლია, და RFC 9111 ადგენს წესებს, რომლებსაც ის მიჰყვება. Cache-Control: no-store ეუბნება ყოველ შესაბამის ქეშს, რომ პასუხი გადააგდოს, მაშინ როცა private ხელახალ გამოყენებას ერთ მომხმარებელზე ზღუდავს, და გრძელი max-age საერთო შენახვას იწვევს. ერთი მოთხოვნა გეუბნებათ, რომელი პოლიტიკა აირჩია წყარომ. გაუშვით ის, სანამ რაიმე სხვაზე კამათს დაიწყებთ.
curl -sI https://origin.example/media/report.pdf | grep -i -E 'cache-control|etag|age'
გრძელ სიცოცხლეს რომ აცხადებს, პასუხი ქეშებს ეუბნება, რომ გადაკვრა პროტოკოლის დონეზე მისაღებია. ეს განცხადება არაფერს ამბობს იმაზე, შეგიძლიათ თუ არა იგივე ობიექტის აღება, ხელახლა ჰოსტინგი და საკუთარ სერვისში ჩასმა. ორი განსხვავებული ნებართვა ორი განსხვავებული მექანიზმიდან მოდის, და ერთის დაკმაყოფილება მეორეს ზუსტად იქ ტოვებს, სადაც იყო.
სარკული შემთხვევა ისევე ვარდება. ბოლოდან ბოლომდე HTTPS ხელს უშლის გამჭვირვალე ქეშს რაიმეს შენახვაში, მაგრამ ეს შედეგი არც მასალის გავრცელების უფლებას ქმნის და არც უკვე არსებულს ართმევს. პროტოკოლის ქცევა ხსნის, რა შეუძლია ყუთს; ის არასოდეს იძლევა უფლებამოსილებას.
რა უნდა ჩაიწეროს სანამ სერვისი ამუშავდება
აღწერეთ შეთანხმება ისეთი ტერმინებით, რომელთა შემოწმება გარეშე ადამიანს შეეძლოს. დაასახელეთ მასალა და მისი წყარო, ჩამოთვალეთ სისტემის მიერ შესრულებული მოქმედებები და თქვით, რამდენ ხანს ცოცხლობს ყოველი შენახული ობიექტი.
შეინახეთ ეს აღწერა გაშლასთან ერთად და არა ვინმეს მეხსიერებაში. როცა საჩივარი მოდის, დასაცავი პოზიციისა და ვარაუდის შორის სხვაობა ჩვეულებრივ თვეების წინ დაწერილი აბზაცია, რომელიც შენახვის ვადას და ლიცენზიას ასახელებს.
მოკლე გადასინჯვის სია ფარავს განმეორებად ხვრელებს:
- მასალის წყარო და მასზე მიმაგრებული პირობები.
- ყოველი შესრულებული მოქმედება: გადაცემა, შენახვა, რედაქტირება, მიწოდება.
- შენახვა ობიექტის კლასის მიხედვით, საათებში ან დღეებში.
- ნებართვა ან შეზღუდვა, რომელსაც მიწოდების ნაბიჯი ეყრდნობა.
- კონტაქტი და მოხსნის გზა უფლებამფლობელებისთვის.
გაატარეთ სია მოქმედ კონფიგურაციაზე და არა არქიტექტურის დიაგრამაზე. სადაც პასუხი აკლია, ის ხვრელი შემდეგი ამოცანაა: ან მიიღეთ ნებართვა მოქმედებისთვის, ან შეწყვიტეთ მისი შესრულება. კომერციული სერვისისთვის, აცალეთ იურისტს წაიკითხოს წერილობითი აღწერა თქვენი იურისდიქციის მიმართ, რადგან აღწერაა ის, რაც ამ გადასინჯვას შესაძლებელს ხდის. ყველაფერი, რასაც წერილობით ვერ აღწერთ, პოზიციაა, რომელსაც ვერ დაიცავთ.