You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
IoT-For-Beginners/translations/bg/2-farm/lessons/6-keep-your-plant-secure/README.md

243 lines
38 KiB

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

<!--
CO_OP_TRANSLATOR_METADATA:
{
"original_hash": "81c437c568eee1b0dda1f04e88150d37",
"translation_date": "2025-08-28T11:16:15+00:00",
"source_file": "2-farm/lessons/6-keep-your-plant-secure/README.md",
"language_code": "bg"
}
-->
# Поддържайте вашето растение защитено
![Скица на урока](../../../../../translated_images/lesson-10.829c86b80b9403bb770929ee553a1d293afe50dc23121aaf9be144673ae012cc.bg.jpg)
> Скица от [Nitya Narasimhan](https://github.com/nitya). Кликнете върху изображението за по-голяма версия.
## Тест преди лекцията
[Тест преди лекцията](https://black-meadow-040d15503.1.azurestaticapps.net/quiz/19)
## Въведение
В последните няколко урока създадохте IoT устройство за мониторинг на почвата и го свързахте с облака. Но какво ще стане, ако хакери, работещи за конкурентен фермер, успеят да поемат контрол над вашите IoT устройства? Какво ще стане, ако те изпратят фалшиви данни за висока влажност на почвата, така че растенията ви никога да не бъдат поливани, или включат напоителната система да работи постоянно, убивайки растенията ви от преполиване и увеличавайки разходите ви за вода?
В този урок ще научите как да защитите IoT устройствата си. Тъй като това е последният урок от този проект, ще научите също как да почистите облачните си ресурси, за да намалите потенциалните разходи.
В този урок ще разгледаме:
* [Защо е необходимо да защитите IoT устройствата си?](../../../../../2-farm/lessons/6-keep-your-plant-secure)
* [Криптография](../../../../../2-farm/lessons/6-keep-your-plant-secure)
* [Защита на вашите IoT устройства](../../../../../2-farm/lessons/6-keep-your-plant-secure)
* [Генериране и използване на X.509 сертификат](../../../../../2-farm/lessons/6-keep-your-plant-secure)
> 🗑 Това е последният урок от този проект, така че след като завършите урока и задачата, не забравяйте да почистите облачните си услуги. Ще ви трябват услугите, за да завършите задачата, така че се уверете, че първо сте я изпълнили.
>
> Ако е необходимо, вижте [ръководството за почистване на проекта](../../../clean-up.md) за инструкции как да направите това.
## Защо е необходимо да защитите IoT устройствата си?
IoT сигурността включва гарантиране, че само очакваните устройства могат да се свързват с вашата облачна IoT услуга и да изпращат телеметрия, и че само вашата облачна услуга може да изпраща команди към устройствата ви. IoT данните също могат да бъдат лични, включително медицински или интимни данни, така че цялото ви приложение трябва да вземе предвид сигурността, за да предотврати изтичането на тези данни.
Ако вашето IoT приложение не е защитено, съществуват редица рискове:
* Фалшиво устройство може да изпрати грешни данни, карайки приложението ви да реагира неправилно. Например, те могат да изпратят постоянни високи показания за влажност на почвата, което означава, че напоителната ви система никога няма да се включи и растенията ви ще умрат от липса на вода.
* Неоторизирани потребители могат да четат данни от IoT устройства, включително лични или критични за бизнеса данни.
* Хакери могат да изпращат команди за управление на устройство по начин, който може да причини повреда на устройството или свързания хардуер.
* Чрез свързване към IoT устройство, хакерите могат да използват това, за да получат достъп до допълнителни мрежи и да проникнат в частни системи.
* Злонамерени потребители могат да получат достъп до лични данни и да ги използват за изнудване.
Това са реални сценарии, които се случват постоянно. Някои примери бяха дадени в предишни уроци, но ето още няколко:
* През 2018 г. хакери използваха отворена WiFi точка за достъп на термостат за аквариум, за да получат достъп до мрежата на казино и да откраднат данни. [The Hacker News - Casino Gets Hacked Through Its Internet-Connected Fish Tank Thermometer](https://thehackernews.com/2018/04/iot-hacking-thermometer.html)
* През 2016 г. Mirai Botnet стартира атака за отказ на услуга срещу Dyn, интернет доставчик, като прекъсна големи части от интернет. Този ботнет използваше зловреден софтуер, за да се свърже с IoT устройства като DVR и камери, които използваха стандартни потребителски имена и пароли, и оттам стартира атаката. [The Guardian - DDoS attack that disrupted internet was largest of its kind in history, experts say](https://www.theguardian.com/technology/2016/oct/26/ddos-attack-dyn-mirai-botnet)
* Spiral Toys имаше база данни с потребители на техните свързани играчки CloudPets, която беше публично достъпна в интернет. [Troy Hunt - Data from connected CloudPets teddy bears leaked and ransomed, exposing kids' voice messages](https://www.troyhunt.com/data-from-connected-cloudpets-teddy-bears-leaked-and-ransomed-exposing-kids-voice-messages/).
* Strava маркираше бегачи, които сте срещнали, и показваше техните маршрути, позволявайки на непознати ефективно да видят къде живеете. [Kim Komndo - Fitness app could lead a stranger right to your home — change this setting](https://www.komando.com/security-privacy/strava-fitness-app-privacy/755349/).
✅ Направете проучване: Потърсете още примери за IoT хакове и пробиви на IoT данни, особено с лични предмети като интернет-свързани четки за зъби или везни. Помислете за въздействието, което тези хакове могат да имат върху жертвите или клиентите.
> 💁 Сигурността е огромна тема и този урок ще засегне само някои от основите, свързани със свързването на вашето устройство с облака. Други теми, които няма да бъдат разгледани, включват мониторинг на промени в данните по време на пренос, хакване на устройства директно или промени в конфигурациите на устройствата. IoT хакването е толкова сериозна заплаха, че са разработени инструменти като [Azure Defender for IoT](https://azure.microsoft.com/services/azure-defender-for-iot/?WT.mc_id=academic-17441-jabenn). Тези инструменти са подобни на антивирусните и защитните инструменти, които може да имате на компютъра си, но са предназначени за малки, нискоенергийни IoT устройства.
## Криптография
Когато устройство се свързва с IoT услуга, то използва идентификатор, за да се идентифицира. Проблемът е, че този идентификатор може да бъде клониран хакер може да настрои злонамерено устройство, което използва същия идентификатор като истинското устройство, но изпраща фалшиви данни.
![И истински, и злонамерени устройства могат да използват един и същ идентификатор, за да изпращат телеметрия](../../../../../translated_images/iot-device-and-hacked-device-connecting.e0671675df74d6d99eb1dedb5a670e606f698efa6202b1ad4c8ae548db299cc6.bg.png)
Решението на този проблем е да се преобразуват данните, които се изпращат, в разбъркан формат, използвайки стойност, известна само на устройството и облака. Този процес се нарича *криптиране*, а стойността, използвана за криптиране на данните, се нарича *ключ за криптиране*.
![Ако се използва криптиране, само криптирани съобщения ще бъдат приети, останалите ще бъдат отхвърлени](../../../../../translated_images/iot-device-and-hacked-device-connecting-encryption.5941aff601fc978f979e46f2849b573564eeb4a4dc5b52f669f62745397492fb.bg.png)
Облачната услуга може след това да преобразува данните обратно в четим формат, използвайки процес, наречен *декриптиране*, като използва или същия ключ за криптиране, или *ключ за декриптиране*. Ако криптираното съобщение не може да бъде декриптирано с ключа, устройството е било хакнато и съобщението се отхвърля.
Техниката за извършване на криптиране и декриптиране се нарича *криптография*.
### Ранна криптография
Най-ранните видове криптография са били шифри за заместване, датиращи отпреди 3500 години. Шифрите за заместване включват заместване на една буква с друга. Например, [шифърът на Цезар](https://wikipedia.org/wiki/Caesar_cipher) включва изместване на азбуката с определен брой позиции, като само изпращачът на криптираното съобщение и предвиденият получател знаят с колко букви да изместят.
[Шифърът на Виженер](https://wikipedia.org/wiki/Vigenère_cipher) отива по-далеч, като използва думи за криптиране на текст, така че всяка буква в оригиналния текст се измества с различно количество, вместо винаги да се измества с един и същ брой букви.
Криптографията е използвана за широк спектър от цели, като защита на рецепта за глазура на грънчар в древна Месопотамия, писане на тайни любовни бележки в Индия или запазване на древноегипетски магически заклинания в тайна.
### Съвременна криптография
Съвременната криптография е много по-напреднала, което я прави по-трудна за разбиване от ранните методи. Тя използва сложна математика за криптиране на данни с твърде много възможни ключове, за да направи атаките чрез груба сила възможни.
Криптографията се използва по много различни начини за сигурна комуникация. Ако четете тази страница в GitHub, може да забележите, че адресът на уебсайта започва с *HTTPS*, което означава, че комуникацията между вашия браузър и уеб сървърите на GitHub е криптирана. Ако някой успее да прочете интернет трафика между вашия браузър и GitHub, той няма да може да прочете данните, тъй като те са криптирани. Вашият компютър дори може да криптира всички данни на твърдия ви диск, така че ако някой го открадне, няма да може да прочете никакви данни без вашата парола.
> 🎓 HTTPS означава HyperText Transfer Protocol **Secure**
За съжаление, не всичко е защитено. Някои устройства нямат никаква защита, други са защитени с лесни за разбиване ключове, а понякога дори всички устройства от един и същ тип използват един и същ ключ. Има случаи на много лични IoT устройства, които всички имат една и съща парола за свързване чрез WiFi или Bluetooth. Ако можете да се свържете със собственото си устройство, можете да се свържете и с чуждо. След като се свържете, можете да получите достъп до много лични данни или да контролирате устройството им.
> 💁 Въпреки сложността на съвременната криптография и твърденията, че разбиването на криптиране може да отнеме милиарди години, възходът на квантовите изчисления доведе до възможността за разбиване на всички известни криптирания за много кратко време!
### Симетрични и асиметрични ключове
Криптирането се дели на два типа - симетрично и асиметрично.
**Симетрично** криптиране използва един и същ ключ за криптиране и декриптиране на данните. И изпращачът, и получателят трябва да знаят един и същ ключ. Това е най-малко сигурният тип, тъй като ключът трябва да бъде споделен по някакъв начин. За да изпрати криптирано съобщение на получател, изпращачът първо може да трябва да изпрати ключа на получателя.
![Симетричното криптиране използва един и същ ключ за криптиране и декриптиране на съобщение](../../../../../translated_images/send-message-symmetric-key.a2e8ad0d495896ffcdf15d25bb4491c695a5cb851457b359fb0f0c89d67707c9.bg.png)
Ако ключът бъде откраднат по време на преноса или ако изпращачът или получателят бъдат хакнати и ключът бъде намерен, криптирането може да бъде разбито.
![Симетричното криптиране е сигурно само ако хакерът не получи ключа - ако го направи, той може да прихване и декриптира съобщението](../../../../../translated_images/send-message-symmetric-key-hacker.e7cb53db1707adfb1486a8144060cb76435fe8dbdede8cecc09e7d15b2d9a251.bg.png)
**Асиметрично** криптиране използва 2 ключа - ключ за криптиране и ключ за декриптиране, наричани публичен/частен ключов чифт. Публичният ключ се използва за криптиране на съобщението, но не може да се използва за декриптиране, а частният ключ се използва за декриптиране на съобщението, но не може да се използва за криптиране.
![Асиметричното криптиране използва различен ключ за криптиране и декриптиране. Ключът за криптиране се изпраща на изпращачите на съобщения, за да могат да криптират съобщение, преди да го изпратят на получателя, който притежава ключовете](../../../../../translated_images/send-message-asymmetric.7abe327c62615b8c19805252af5d4b6c5e7aaeb8fbc455efeff866fe2d300b62.bg.png)
Получателят споделя своя публичен ключ, а изпращачът го използва, за да криптира съобщението. След като съобщението бъде изпратено, получателят го декриптира с частния си ключ. Асиметричното криптиране е по-сигурно, тъй като частният ключ се пази в тайна от получателя и никога не се споделя. Всеки може да има публичния ключ, тъй като той може да се използва само за криптиране на съобщения.
Симетричното криптиране е по-бързо от асиметричното, но асиметричното е по-сигурно. Някои системи използват и двете - използват асиметрично криптиране, за да криптират и споделят симетричния ключ, а след това използват симетричния ключ за криптиране на всички данни. Това прави споделянето на симетричния ключ между изпращача и получателя по-сигурно и по-бързо при криптиране и декриптиране на данни.
## Защита на вашите IoT устройства
IoT устройствата могат да бъдат защитени чрез симетрично или асиметрично криптиране. Симетричното е по-лесно, но по-малко сигурно.
### Симетрични ключове
Когато настроихте вашето IoT устройство да взаимодейства с IoT Hub, използвахте низ за връзка. Пример за низ за връзка е:
```output
HostName=soil-moisture-sensor.azure-devices.net;DeviceId=soil-moisture-sensor;SharedAccessKey=Bhry+ind7kKEIDxubK61RiEHHRTrPl7HUow8cEm/mU0=
```
Този низ за връзка се състои от три части, разделени със запетаи, като всяка част е ключ и стойност:
| Ключ | Стойност | Описание |
| --- | ----- | ----------- |
| HostName | `soil-moisture-sensor.azure-devices.net` | URL на IoT Hub |
| DeviceId | `soil-moisture-sensor` | Уникален идентификатор на устройството |
| SharedAccessKey | `Bhry+ind7kKEIDxubK61RiEHHRTrPl7HUow8cEm/mU0=` | Симетричен ключ, известен на устройството и IoT Hub |
Последната част от този низ за връзка, `SharedAccessKey`, е симетричният ключ, известен както на устройството, така и на IoT Hub. Този ключ никога не се изпраща от устройството към облака или от облака към устройството. Вместо това той се използва за криптиране на данни, които се изпращат или получават.
✅ Направете експеримент. Какво мислите, че ще се случи, ако промените частта `SharedAccessKey` от низа за връзка, когато свързвате вашето IoT устройство? Опитайте.
Когато устройството за първи път се опитва да се свърже, то изпраща токен за споделен достъп (SAS), състоящ се от URL на IoT Hub, времева отметка, когато токенът ще изтече (обикновено 1 ден от текущото време), и подпис. Този подпис се състои от URL и времето на изтичане, криптирани със споделения ключ за достъп от низа за връзка.
IoT Hub декриптира този подпис със споделения ключ за достъп и ако декриптираната стойност съвпада с URL и времето на изтичане, устройството получава разрешение за свързване. Също така проверява дали текущото време
💁 Поради срока на валидност, вашето IoT устройство трябва да знае точния час, който обикновено се получава от [NTP](https://wikipedia.org/wiki/Network_Time_Protocol) сървър. Ако времето не е точно, връзката ще се провали.
След свързването, всички данни, изпратени към IoT Hub от устройството или към устройството от IoT Hub, ще бъдат криптирани с ключа за споделен достъп.
✅ Какво мислите, че ще се случи, ако множество устройства споделят една и съща връзка?
> 💁 Лоша практика за сигурност е да съхранявате този ключ в кода. Ако хакер получи достъп до вашия изходен код, той може да получи ключа ви. Освен това е по-трудно при пускане на код, тъй като ще трябва да прекомпилирате с актуализиран ключ за всяко устройство. По-добре е този ключ да се зарежда от хардуерен модул за сигурност - чип на IoT устройството, който съхранява криптирани стойности, които могат да бъдат прочетени от вашия код.
>
> Когато учите IoT, често е по-лесно да поставите ключа в кода, както направихте в предишен урок, но трябва да се уверите, че този ключ не е качен в публичен контрол на изходния код.
Устройствата имат 2 ключа и 2 съответстващи низове за връзка. Това позволява ротация на ключовете - тоест преминаване от един ключ към друг, ако първият бъде компрометиран, и повторно генериране на първия ключ.
### X.509 сертификати
Когато използвате асиметрично криптиране с двойка публичен/частен ключ, трябва да предоставите публичния си ключ на всеки, който иска да ви изпрати данни. Проблемът е как получателят на вашия ключ може да бъде сигурен, че това наистина е вашият публичен ключ, а не някой друг, който се представя за вас? Вместо да предоставяте ключ, можете да предоставите публичния си ключ в сертификат, който е проверен от доверена трета страна, наречена X.509 сертификат.
X.509 сертификатите са цифрови документи, които съдържат публичната част от двойката публичен/частен ключ. Те обикновено се издават от една от редица доверени организации, наречени [сертификационни органи](https://wikipedia.org/wiki/Certificate_authority) (CAs), и са цифрово подписани от CA, за да се посочи, че ключът е валиден и идва от вас. Вие се доверявате на сертификата и че публичният ключ е от този, който сертификатът твърди, че е, защото се доверявате на CA, подобно на това как бихте се доверили на паспорт или шофьорска книжка, защото се доверявате на държавата, която го издава. Сертификатите струват пари, така че можете също да „самоподписвате“, тоест да създадете сертификат сами, който е подписан от вас, за тестови цели.
> 💁 Никога не трябва да използвате самоподписан сертификат за продукционна версия.
Тези сертификати имат редица полета, включително кой е източникът на публичния ключ, подробности за CA, който го е издал, колко дълго е валиден и самия публичен ключ. Преди да използвате сертификат, добра практика е да го проверите, като се уверите, че е подписан от оригиналния CA.
✅ Можете да прочетете пълен списък с полетата в сертификата в [урока на Microsoft за разбиране на X.509 публични ключови сертификати](https://docs.microsoft.com/azure/iot-hub/tutorial-x509-certificates?WT.mc_id=academic-17441-jabenn#certificate-fields).
Когато използвате X.509 сертификати, както изпращачът, така и получателят ще имат свои собствени публични и частни ключове, както и X.509 сертификати, които съдържат публичния ключ. Те след това обменят X.509 сертификати по някакъв начин, използвайки публичните ключове един на друг, за да криптират данните, които изпращат, и своите частни ключове, за да декриптират данните, които получават.
![Вместо да споделяте публичен ключ, можете да споделите сертификат. Потребителят на сертификата може да провери, че идва от вас, като се свърже със сертификационния орган, който го е подписал.](../../../../../translated_images/send-message-certificate.9cc576ac1e46b76eb58ebc8eedaa522566fa0700076da46f5180aad78c2435db.bg.png)
Едно голямо предимство на използването на X.509 сертификати е, че те могат да бъдат споделяни между устройства. Можете да създадете един сертификат, да го качите в IoT Hub и да го използвате за всички ваши устройства. Всяко устройство трябва само да знае частния ключ, за да декриптира съобщенията, които получава от IoT Hub.
Сертификатът, използван от вашето устройство за криптиране на съобщенията, които изпраща към IoT Hub, е публикуван от Microsoft. Това е същият сертификат, който много Azure услуги използват и понякога е вграден в SDK-ите.
> 💁 Запомнете, публичният ключ е точно това - публичен. Публичният ключ на Azure може да се използва само за криптиране на данни, изпратени към Azure, а не за тяхното декриптиране, така че може да бъде споделян навсякъде, включително в изходния код. Например, можете да го видите в [изходния код на Azure IoT C SDK](https://github.com/Azure/azure-iot-sdk-c/blob/master/certs/certs.c).
✅ Има много жаргон, свързан с X.509 сертификатите. Можете да прочетете дефинициите на някои от термините, които може да срещнете, в [Ръководството за X.509 сертификатен жаргон за начинаещи](https://techcommunity.microsoft.com/t5/internet-of-things/the-layman-s-guide-to-x-509-certificate-jargon/ba-p/2203540?WT.mc_id=academic-17441-jabenn).
## Генериране и използване на X.509 сертификат
Стъпките за генериране на X.509 сертификат са:
1. Създайте двойка публичен/частен ключ. Един от най-широко използваните алгоритми за генериране на двойка публичен/частен ключ се нарича [RivestShamirAdleman](https://wikipedia.org/wiki/RSA_(cryptosystem))(RSA).
1. Изпратете публичния ключ с асоциирани данни за подписване, или от CA, или чрез самоподписване.
Azure CLI има команди за създаване на нова идентичност на устройство в IoT Hub и автоматично генериране на двойка публичен/частен ключ и създаване на самоподписан сертификат.
> 💁 Ако искате да видите стъпките в детайли, вместо да използвате Azure CLI, можете да ги намерите в [урока за използване на OpenSSL за създаване на самоподписани сертификати в документацията на Microsoft IoT Hub](https://docs.microsoft.com/azure/iot-hub/tutorial-x509-self-sign?WT.mc_id=academic-17441-jabenn).
### Задача - създаване на идентичност на устройство с X.509 сертификат
1. Изпълнете следната команда, за да регистрирате новата идентичност на устройството, автоматично генерирайки ключовете и сертификатите:
```sh
az iot hub device-identity create --device-id soil-moisture-sensor-x509 \
--am x509_thumbprint \
--output-dir . \
--hub-name <hub_name>
```
Заменете `<hub_name>` с името, което сте използвали за вашия IoT Hub.
Това ще създаде устройство с идентификатор `soil-moisture-sensor-x509`, за да се разграничи от идентичността на устройството, която създадохте в предишния урок. Тази команда също ще създаде 2 файла в текущата директория:
* `soil-moisture-sensor-x509-key.pem` - този файл съдържа частния ключ за устройството.
* `soil-moisture-sensor-x509-cert.pem` - това е X.509 сертификатният файл за устройството.
Пазете тези файлове безопасно! Файлът с частния ключ не трябва да бъде качван в публичен контрол на изходния код.
### Задача - използване на X.509 сертификат в кода на вашето устройство
Работете през съответното ръководство, за да свържете вашето IoT устройство към облака, използвайки X.509 сертификат:
* [Arduino - Wio Terminal](wio-terminal-x509.md)
* [Едноплатков компютър - Raspberry Pi/Виртуално IoT устройство](single-board-computer-x509.md)
---
## 🚀 Предизвикателство
Има множество начини за създаване, управление и изтриване на Azure услуги като Resource Groups и IoT Hubs. Един от тях е [Azure Portal](https://portal.azure.com?WT.mc_id=academic-17441-jabenn) - уеб-базиран интерфейс, който ви предоставя GUI за управление на вашите Azure услуги.
Посетете [portal.azure.com](https://portal.azure.com?WT.mc_id=academic-17441-jabenn) и разгледайте портала. Вижте дали можете да създадете IoT Hub чрез портала, след което да го изтриете.
**Подсказка** - когато създавате услуги чрез портала, не е необходимо предварително да създавате Resource Group, такава може да бъде създадена, когато създавате услугата. Уверете се, че я изтривате, когато приключите!
Можете да намерите много документация, уроци и ръководства за Azure Portal в [документацията за Azure Portal](https://docs.microsoft.com/azure/azure-portal/?WT.mc_id=academic-17441-jabenn).
## Тест след лекцията
[Тест след лекцията](https://black-meadow-040d15503.1.azurestaticapps.net/quiz/20)
## Преглед и самостоятелно обучение
* Прочетете за историята на криптографията на [страницата за историята на криптографията в Wikipedia](https://wikipedia.org/wiki/History_of_cryptography).
* Прочетете за X.509 сертификатите на [страницата за X.509 в Wikipedia](https://wikipedia.org/wiki/X.509).
## Задание
[Създайте ново IoT устройство](assignment.md)
---
**Отказ от отговорност**:
Този документ е преведен с помощта на AI услуга за превод [Co-op Translator](https://github.com/Azure/co-op-translator). Въпреки че се стремим към точност, моля, имайте предвид, че автоматизираните преводи може да съдържат грешки или неточности. Оригиналният документ на неговия роден език трябва да се счита за авторитетен източник. За критична информация се препоръчва професионален човешки превод. Ние не носим отговорност за недоразумения или погрешни интерпретации, произтичащи от използването на този превод.