რეკლამის დახურვა

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

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

მონაცემთა გაფართოებული დაცვა iOS 16.3-ში

Apple რამდენიმე წლის განმავლობაში მწვავედ აკრიტიკებდნენ ამ არასრულყოფილი დაშიფვრის სისტემის გამო. დიდი ხნის ლოდინის შემდეგ საბოლოოდ მივიღეთ სასურველი ცვლილება. ახალი ოპერაციული სისტემების iOS 16.3, iPadOS 16.3, macOS 13.2 Ventura და watchOS 9.3 მოსვლასთან ერთად გამოჩნდა მონაცემთა გაფართოებული ე.წ. ის უშუალოდ აგვარებს ზემოხსენებულ ხარვეზებს – ავრცელებს ბოლოდან ბოლომდე დაშიფვრას ყველა ელემენტზე, რომელთა სარეზერვო ასლებიც არის iCloud-ის საშუალებით. შედეგად, Apple კარგავს წვდომას ვაშლის გამყიდველის მონაცემებზე. პირიქით, ამგვარად, კონკრეტული მომხმარებელი ხდება ერთადერთი, ვისაც აქვს წვდომის გასაღებები და რომელსაც შეუძლია რეალურად იმუშაოს მოცემულ მონაცემებთან.

advanced-data-protection-ios-16-3-fb

მიუხედავად იმისა, რომ ჩვენ ვნახეთ მონაცემთა გაფართოებული დაცვის მოსვლა iCloud-ზე და პრაქტიკულად საბოლოოდ მივიღეთ სარეზერვო მონაცემების სრული უსაფრთხოების ვარიანტი, ეს ვარიანტი ჯერ კიდევ საკმაოდ იმალება სისტემებში. თუ გაინტერესებთ, უნდა გაააქტიუროთ (სისტემა) პარამეტრები > [თქვენი სახელი] > iCloud > მონაცემთა გაფართოებული დაცვა. როგორც ზემოთ აღვნიშნეთ, ამ ფუნქციის გააქტიურებით, თქვენ ხდებით ექსკლუზიური მომხმარებელი, რომელსაც აქვს წვდომა სარეზერვო ასლებსა და მონაცემებზე. ამ მიზეზით, აბსოლუტურად გადამწყვეტია აღდგენის ვარიანტების დაყენება. ამ მხრივ შეიძლება გამოყენებულ იქნას სანდო კონტაქტი ან აღდგენის გასაღები. თუ თქვენ აირჩევთ, მაგალითად, ზემოხსენებულ გასაღებს და შემდეგ დაივიწყებთ/დაკარგავთ მას, უბრალოდ არ იღბალი. ვინაიდან მონაცემები დაშიფრულია და მასზე წვდომა არავის აქვს, გასაღების დაკარგვის შემთხვევაში ყველაფერს დაკარგავთ.

რატომ არ არის დამატებითი დაცვა ავტომატური?

ამავე დროს, ის გადადის საკმაოდ მნიშვნელოვან კითხვაზე. რატომ არ არის ავტომატურად ჩართული iCloud Advanced Data Protection ახალ ოპერაციულ სისტემებზე? ამ ფუნქციის გააქტიურებით პასუხისმგებლობა გადადის მომხმარებელზე და მთლიანად მათზეა დამოკიდებული, როგორ მოიქცნენ ამ ვარიანტთან. თუმცა, უსაფრთხოების გარდა, Apple ძირითადად ეყრდნობა სიმარტივეს - და ეს ბევრად უფრო ადვილია, თუ გიგანტს აქვს შესაძლებლობა დაეხმაროს თავის მომხმარებელს მონაცემთა შესაძლო აღდგენაში. უბრალო ტექნიკურად გამოუცდელ მომხმარებელს შეუძლია, პირიქით, პრობლემები შეუქმნას.

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

.