Протягом останніх кількох місяців сталося ДУЖЕ багато цікавого у світі засобів ідентифікації та стандартів безпеки. Завдяки зусиллям широкого кола галузевих експертів ми досягли неймовірного прогресу, завершивши розробку великого набору нових і вдосконалених стандартів, які поліпшать безпеку та зроблять хмарні служби й пристрої зручнішими для користувача.

Одним із найважливіших серед цих удосконалень є родина специфікацій Token Binding, яка зараз очікує остаточної ратифікації від Спеціальної комісії інтернет-розробок (Internet Engineering Task Force, IETF). (Щоб дізнатися більше про технологію прив’язки маркерів (Token Binding), перегляньте цю чудову презентацію від Брайана Кемпбелла.)

У Microsoft ми вважаємо, що специфікації Token Binding можуть значно підвищити безпеку одночасно для компаній і пересічних користувачів, зробивши високоефективні технології ідентифікації та автентифікації широко- й легкодоступним для розробників у всьому світі.

З огляду на те, наскільки позитивними на нашу думку виявилися ці зрушення, ми й надалі віддано співпрацюватимемо зі спільнотою, створюючи та впроваджуючи родину специфікацій Token Binding.

Тепер, коли специфікації близькі до ратифікації, мені б хотілося, щоб ви зробили наступне:

1. Почніть експериментувати зі стандартом Token Binding і відповідним чином планувати свої розробки.
2. Зверніться до своїх постачальників браузерів та іншого програмного забезпечення з проханням реалізувати специфікації Token Binding у своїх продуктах, якщо вони ще цього не зробили.

З радістю повідомляю, що корпорація Майкрософт – один із багатьох авторитетних представників галузі, які відкрито заявляють про важливість рішення Token Binding, час якого вже настав.

Оцінити, чому технології прив’язки маркерів настільки важливі, нам допоможе Памела Дінгл – провідний експерт у галузі, уже добре відомий багатьом із вас. Тепер вона ще й директор відділу Microsoft із питань стандартів ідентичності в підрозділі Azure AD.

З повагою,

Алекс Сімонс (Twitter: @Alex_A_Simons)

Начальник відділу керування програмами

Відділ технологій ідентифікації, корпорація Майкрософт

—————————————————————————————————————————–

Дякую, Алекс, і привіт усім!

Не можу не поділяти захоплення Алекса. На розробку специфікацій пішли роки роботи й безліч зусиль. І незабаром вони стануть новими стандартами RFC. Настав час для архітекторів усвідомити конкретні переваги ідентифікації та безпеки, які надає стандарт Token Binding.

“Що ж такого особливого в технології прив’язки маркерів?” – запитаєте ви. Прив’язка маркерів робить файли cookie, маркери доступу OAuth і маркери оновлення, а також маркери OpenID Connect ID непридатними для використання поза контекстом TLS, у якому їх створили. Зазвичай це маркери носія – той, хто володіє ними, може “обміняти” їх на ресурси. Але прив’язка маркерів вдосконалює цю систему: накладається механізм підтвердження, який дає змогу зіставити криптографічні матеріали, зібрані під час видавання й використання маркера. Тільки правильний клієнт, який використовує необхідний канал TLS, пройде перевірку. Процес, у ході якого примушують об’єкт, що надає маркер, підтвердити свої повноваження, називається “встановленням права володіння”.

Виявляється, що файли cookie й маркери можуть використовуватися за межами вихідного контексту TLS у зловмисних цілях. Це можуть бути вкрадені файли cookie сеансу, втрачені маркери доступу або витончена атака посередника (MiTM). Саме тому в проекті актуальних практичних порад щодо безпеки IETF OAuth 2 рекомендується використовувати Token Binding, а ми нещодавно подвоїли винагороди в рамках програми заохочення учасників до популяризації засобів перевірки ідентичності. Тепер, коли ми вимагаємо підтвердити право володіння, зловмиснику, щоб скористатися файлами cookie або маркерами з метою, для якої вони не призначені, довелося б вдатися до занадто складних і дорогих методів.

Як і будь-який механізм установлення права володіння, прив’язка маркерів дає нам змогу побудувати поглиблений комплексний захист. Ми можемо докладати багато зусиль, щоб не втратити маркер, проте ми також маємо змогу перевірити його, аби залишатися захищеними. Прив’язка маркерів – це автономне та прозоре для користувача рішення, на відміну від інших механізмів, що дають змогу встановити право володіння, як-от клієнтські сертифікати. Причому більша частина складних операцій виконується інфраструктурою. Ми сподіваємося, що зрештою кожен зможе почати працювати з технологіями, які забезпечують ефективний контроль ідентичності. Але спершу ми очікуємо на попит із боку державних і фінансових установ, які змушені виконувати поточні нормативні вимоги щодо встановлення права володіння. Для прикладу, ця технологія знадобиться кожному, хто потребує рівня автентифікації AAL3 за стандартом NIST 800-63C.

Token Binding – результат тривалої праці. Ми займаємося цим уже три роки, і хоча ратифікація специфікацій – важливий етап, нам, як творцям екосистеми, ще багато чого потрібно зробити. Щоб ця специфікація стала ефективною, її мають реалізовувати різні постачальники на різноманітних платформах. Ми дуже раді, що в найближчі місяці почнемо активно розповідати про переваги цієї технології для системи безпеки й ділитимемося практичними порадами з власного досвіду. Ми сподіваємося, що ви, як і ми, прагнутимете поширити це рішення всюди, де воно вам знадобиться.

Усього найкращого,

Пам

The post Прив’язка маркерів (Token Binding) – час прийшов! appeared first on Microsoft 365 Blog.

Радо оголошуємо про випуск оновлених і покращених можливостей батьківського контролю в облікових записах Microsoft для країн Європейського Союзу. Це важливий крок у забезпеченні для користувачів можливостей відповідно до Загального регламенту про захист даних (General Data Privacy Regulation, GDPR).

Корпорація Майкрософт переконана, що діти – це важлива складова екосистеми користувачів, хоч би вони грали в Minecraft, спілкувалися в чаті Skype із дідусями та бабусями чи дивилися мультики про Свинку Пеппу на Surface Book. Ми також вважаємо, що батьки й опікуни повинні мати належні засоби захисту. Саме тому корпорація Майкрософт уже давно дотримується положень COPPA, а також подібних світових норм.

Відповідно до положень GDPR, батьки мають надавати згоду на обробку персональних даних дітей віком до 16 років. Країни-члени ЄС можуть установити менший вік (деякі з них уже скористалися цим правом), але вікове обмеження не може становити менше 13 років. Закон США про захист конфіденційності дітей в Інтернеті (Children’s Online Privacy Protection Act, COPPA) і GDPR мають багато однакових положень, тому ми об’єднали їх, щоб забезпечити відповідність суворішим вимогам.

Для цього нашим системам потрібна змога дізнаватися, які з користувачів облікових записів Microsoft дорослі, а які – діти, використовуючи методи, прийнятні згідно з різноманітними вимогами законодавства.

Для цього ми запитуємо дату народження користувачів усіх облікових записів, які повинні відповідати вимогам. Якщо хтось із користувачів не вказав такі дані, ми показуватимемо сповіщення з проханням зазначити країну й дату народження. Якщо з’ясується, що користувач молодший, ніж визначено вимогами для відповідної країни, під час його входу в обліковий запис з’являтиметься запит на згоду від батьків. (Зверніть увагу: діятиме певний пільговий період, протягом якого батьки мають пройти процедуру перевірки.)

Щоб надати згоду на використання облікового запису, батьки можуть підтвердити, що вони повнолітні, указавши дані кредитної картки. Батьки, у яких немає кредитної картки або які не хочуть указувати її дані, можуть скористатися альтернативними методами, щоб підтвердити свій вік. Батьки можуть зв’язатися зі службою підтримки, щоб підтвердити свій вік і особу за допомогою відповідних державних документів. Після завершення пільгового періоду доступ до облікового запису дитини буде заблоковано, доки батьки не дадуть згоду на його використання та не пройдуть процедуру перевірки.

Ми розуміємо, що потрібен певний час, щоб виконати ці умови. Як і решта подібних компаній у галузі, ми використовуємо дані кредитної картки, щоб підтвердити вік користувача. Підтвердження віку за допомогою кредитної картки – це один із затверджених законодавством способів. Ми вже довгий час дотримуємося стандартів у галузі рішень для керування ідентичностями, що дає батькам по всьому світу змогу підтверджувати свою особу безпечно, конфіденційно та за всіма правилами.

Ми ретельно стежимо за впровадженням вимог і досліджуємо всі проблеми, які з’являються. Ми відслідковуємо тенденції серед дорослих, яких просять надати згоду для дітей. У всіх випадках нам удалося відстежити користувачів, які навмисно або помилково вказали таку дату народження, за якої вони вважаються неповнолітніми особами. Ми додали кілька механізмів, які мають допомогти вирішити цю проблему, але все одно маємо обов’язково переконатися, що користувач – доросла людина. Ми продовжимо шукати способи, як покращити цю процедуру. Звісно, наша мета – дати всім користувачам змогу повідомляти нам правильну дату народження з мінімальним відхиленням.

Сподіваємося, що ви ознайомитеся з відомостями про цю нову функцію, а ми вдосконалюватимемо сценарії, які допоможуть батькам захистити своїх дітей в Інтернеті.

Будемо раді отримати ваші відгуки та пропозиції.

З повагою,

Алекс Сімонс (Twitter: @Alex_A_Simons)

Начальник відділу керування програмами

Відділ технологій ідентифікації, корпорація Майкрософт

The post Запровадження функцій, пов’язаних із віковими обмеженнями в облікових записах Microsoft, у рамках дотримання вимог GDPR appeared first on Microsoft 365 Blog.

Багато хто з вас, мабуть, уже застосовує співпрацю B2B в Azure Active Directory (Azure AD) для роботи із зовнішніми партнерами. Рік тому ми додали можливості B2B в Azure AD, і з того часу понад 800 000 організацій застосували їх для співпраці з партнерами та створили 8 мільйонів облікових записів гостя. Вражає, чи не так?!

У відгуках клієнти частіше за все писали про те, що їм потрібні засоби співпраці B2B для роботи з усіма програмами навіть за гібридної конфігурації, коли залучаються як локальні ресурси, так і хмара. Уявімо, що ви вже використовуєте засоби співпраці B2B, щоб надавати партнерам доступ до програм в Azure або Office 365 із використанням їхніх зовнішніх облікових даних. Але у вашій організації є цінні програми, які ви ще не готові перемістити до хмари.

З радістю повідомляємо про випуск загальнодоступної підготовчої версії, у якій користувачам засобів B2B в Azure AD можна надати доступ до локальних програм, не створюючи вручну локальні облікові записи!

Такі локальні програми можуть використовувати автентифікацію на базі SAML або вбудовану автентифікацію Windows з обмеженим делегуванням Kerberos. Це означає, що працівники компаній-партнерів можуть використовувати свої робочі облікові записи й дані, щоб просто та безпечно отримувати доступ до всіх вибраних вами хмарних і локальних програм. Крім того, ви можете застосовувати політики умовного доступу та керування життєвим циклом в Azure AD, щоб захищати ресурси так само, як і для своїх співробітників.

Перш ніж розпочинати роботу, радимо ознайомитися з документами. Надати працівникам і партнерам можливість співпрацювати без жодних проблем за гібридної конфігурації зовсім просто! 

Будемо вдячні, якщо ви поділитеся з нами відгуком, враженнями та пропозиціями. Ми завжди прислухаємося до думок клієнтів! 

З повагою,
Алекс Сімонс (@Twitter: @Alex_A_Simons)
Начальник відділу керування програмами
Відділ технологій ідентифікації, корпорація Майкрософт 

The post Співпраця B2B з використанням Azure AD для гібридних організацій appeared first on Microsoft 365 Blog.

Сьогодні я хочу розповісти вам про деякі нові функції, над якими ми працювали останнім часом. Думаю, вони вам сподобаються. Пропонуємо вашій увазі такі нові можливості:

1. З наступним оновленням Windows 10, яке ми випустимо до кінця весни, ви отримаєте підготовчу версію функції безпарольного входу за допомогою ключа безпеки FIDO2 (вона вийде в обмеженому доступі).
2. Тепер політики умовного доступу Azure Active Directory можуть перевіряти справність пристроїв за даними “Розширеного захисту від загроз для Захисника Windows”.
3. Функції перевірок доступу, умов використання, а також Privileged Identity Management в Azure Active Directory стали загальнодоступними.
4. У службі співпраці B2B в Azure Active Directory з’явилися списки дозволених і заборонених доменів, що дає змогу контролювати, з якими партнерськими організаціями ви співпрацюєте.

Щоб дізнатися більше, читайте далі!

З наступним оновленням Windows 10, яке ми випустимо до кінця весни, ви отримаєте підготовчу версію функції безпарольного входу за допомогою ключа безпеки FIDO2 (вона вийде в обмеженому доступі).

Якщо ви хочете підвищити надійність своїх захисних систем, а також знизити ризик фішингових атак і витрати на керування паролями, то будете в захваті від підтримки FIDO2 у Windows 10.

У наступному оновленні Windows 10 з’явиться підтримка ключів безпеки FIDO2 як підготовча версія функції (в обмеженому доступі). Завдяки ній ваші працівники зможуть входити на ПК з Windows 10 і підключенням до Azure Active Directory без імені користувача та пароля. Для цього їм достатньо лише вставити в USB-порт ключ безпеки, який відповідає стандартам FIDO2, і торкнутися сканера відбитків пальців. Після цього вони автоматично ввійдуть на пристрій і отримають доступ до всіх ваших хмарних ресурсів під захистом Azure Active Directory.

Подивіться, як це працює:

Звісно, нам ще є над чим працювати: потрібно додати підтримку гібридних середовищ, делегованого створення ключів тощо. Проте вихід цієї функції стане ДУЖЕ великим кроком на шляху до безпарольного світу. Уся наша команда надзвичайно радіє, що початок покладено.

Тепер політики умовного доступу Azure Active Directory можуть перевіряти справність пристроїв за даними “Розширеного захисту від загроз для Захисника Windows”.

Ми також оголошуємо про вдосконалений умовний доступ Azure Active Directory, який тепер інтегровано з Intune і “Розширеним захистом від загроз для Захисника Windows”. У ньому можна створювати політики доступу на основі рівня ризику, виявленого на кінцевих точках Windows 10. Так ви будете впевнені, що корпоративна інформація потраплятиме до рук тільки довірених користувачів, які працюють на надійних пристроях. А якщо до Azure Active Directory надходитимуть дані про підозрілі дії на пристроях, підключених до домену, політика відразу блокуватиме їм доступ до корпоративних ресурсів.

Подивіться відео та дізнайтеся більше про те, як працює ця інтеграція.

Інші чудові новини

У нас є ще кілька новин, які можуть вам сподобатися.

Минулого року на конференції Ignite 2017 ми оголосили про появу загальнодоступної підготовчої версії таких функцій, як перевірка доступу та умови використання, а також Privileged Identity Management (PIM), в Azure Active Directory. А тепер ці функції стали загальнодоступними в Azure AD Premium.

• Перевірки доступу допомагають стежити за тим, щоб права доступу користувачів завжди залишались актуальними. Такі перевірки можна проводити за графіком, автоматично застосовуючи результати, щоб запобігти порушенням відповідності.
  
• PIM для ресурсів Azure: тепер за допомогою Azure AD PIM в Azure Active Directory можна призначати ролі й обмеження доступу за часом, щоб захистися від зловмисників. Наприклад, можна вимагати, щоб користувачі, які запитують підвищення до ролі співавтора віртуальної машини, проходили багатофакторну автентифікацію або процедуру затвердження повноважень.
  
• Умови використання стануть у пригоді, коли потрібно поінформувати ваших співробітників і партнерів про правила роботи з певними даними, які вони хочуть відкрити. Багато клієнтів зверталися до нас із проханням додати таку функцію, а регламент GDPR, який набуває чинності 25 травня 2018 року, тільки підвищив потребу в ній. І відтепер вона доступна для всіх клієнтів. А ще ми нещодавно додали підтримку різних мов і нові докладні звіти, які показують, хто й коли прийняв певні умови.
  

У службі співпраці B2B в Azure Active Directory з’явилися списки дозволених і заборонених доменів, завдяки чому можна контролювати, з якими партнерськими організаціями ви співпрацюєте.

Вибирайте, з якими партнерськими організаціями співпрацювати й ділитися даними. У службі співпраці B2B в Azure Active Directory з’явилися списки дозволених і заборонених доменів. Якщо ви не хочете, щоб ваші працівники надсилали запрошення людям із певного домену, просто додайте його до списку заборонених.

Так ви зможете контролювати доступ до своїх ресурсів без жодних проблем для схвалених користувачів.

Нова функція доступна для всіх клієнтів Azure Active Directory, і її можна використовувати разом із функціями Azure AD Premium (умовним доступом, захистом ідентичностей тощо). Так ви зможете краще контролювати, коли та як користувачі з інших компаній входять у ваші системи й отримують доступ до даних.

Дізнайтеся більше.

Прикінцеве слово

Ми дуже раді запропонувати вам ці нові можливості для керування паролями, захисту ідентичностей і боротьби із загрозами. А незабаром виходить ще й підготовча версія функції безпарольного входу до Windows за допомогою Azure Active Directory. Доступ до неї буде обмежено, тож якщо ви хочете її випробувати, запишіться вже зараз.

Як завжди, нам буде дуже приємно, якщо ви поділитеся своєю думкою щодо цих новин. Чекаємо на ваші відгуки та пропозиції!

З повагою,

Алекс Сімонс (Twitter: @Alex_A_Simons),

начальник відділу керування програмами,

відділення технологій ідентифікації, корпорація Майкрософт

The post Уже скоро завдяки FIDO2 можна буде входити до Windows 10 і Azure Active Directory без пароля (є ще й інші чудові новини) appeared first on Microsoft 365 Blog.

Сподіваюся, цей допис буде таким само цікавим для вас, як і для мене, адже сьогодні ми поговоримо про майбутнє цифрових ідентичностей.

Протягом останнього року ми активно працювали над розробкою нових ідей із використання ланцюжків блоків транзакцій та інших технологій, у яких застосовуються розподілені реєстри. Ми сподівалися створити цілковито нові, безпечніші типи цифрових ідентичностей, які б гарантували легке керування та конфіденційність персональних даних. Під час роботи ми зробили багато цікавих відкриттів і налагодили співробітництво з новими партнерами. Тому сьогодні ми радо ділимося з вами нашими ідеями та планами. Допис входить до серії публікацій, це логічне продовження матеріалу Пеггі Джонсон про те, що корпорація Майкрософт приєдналася до ініціативи ID2020. Якщо ви його ще не читали, рекомендую спершу з ним ознайомитися.

Автор цього допису – Анкур Патель, спеціаліст із мого відділу та менеджер проектів, присвячених нашим новим розробкам. Він люб’язно погодився розповісти читачам цього блоґу про децентралізовані цифрові ідентичності, зокрема про наші ключові висновки та принципи, згідно з якими ми плануємо інвестувати в подальші розробки.

Як завжди, ми будемо дуже раді вашим відгукам і пропозиціям.

З найщирішими побажаннями,

Алекс Сімонс (Twitter: @Alex_A_Simons),

начальник відділу керування програмами,

відділення технологій ідентифікації, корпорація Майкрософт

————

Вітаю! Я Анкур Патель із відділення технологій ідентифікації в корпорації Майкрософт. Для мене велика честь поділитися з вами деякими з наших знахідок і планів щодо нових розробок, присвячених створенню децентралізованих ідентичностей на основі ланцюжків блоків транзакцій (розподілених реєстрів).

Навіщо ми над цим працюємо

Для всіх нас очевидно, що у світі відбувається глобальна цифрова трансформація. Віртуальна та фізична реальності навколо нас дедалі більше зливаються в одне ціле. І цей новий світ вимагає нової, безпечнішої та приватнішої моделі цифрових ідентичностей.

Системи хмарної ідентифікації від корпорації Майкрософт уже дають тисячам організацій і розробників та мільярдам звичайних людей можливість працювати ефективніше, відпочивати краще й досягати нових висот. Але ми можемо запропонувати людям набагато більше. Ми прагнемо створити світ, у якому мільярди всіх тих, які нині живуть без надійних документів, зможуть нарешті здійснити свої прості людські мрії: жити краще, вивчити дітей, започаткувати свою справу.

Ми переконані: для цього кожна людина має сама повністю розпоряджатися своєю цифровою ідентичністю. Зараз дані наших ідентичностей розкидано по численним стороннім програмам і службам, яким ми дозволяємо збирати інформацію про себе. Так не має бути. Потрібно створити безпечний електронний центр, де в зашифрованому вигляді зберігатимуться всі компоненти цифрових ідентичностей, щоб власники легко могли контролювати доступ до них.

Кожному з нас потрібна власна цифрова ідентичність, де безпечно й конфіденційно зберігатимуться відомості про нас.  Вона повинна давати нам повний контроль над доступом до неї й використанням її даних, а також бути зручною.

Ми знаємо, що дати людям у руки таку владу над даними про себе – це щось більше, ніж прерогатива однієї компанії або організації. Тож ми плануємо тісно співпрацювати з нашими клієнтами, партнерами та членами спільноти розробників. Ми дуже раді, що разом із нами над новим поколінням цифрових ідентичностей працює стільки талановитих людей із нашої галузі.

Які висновки ми зробили

Зараз я хочу розповісти вам, яких висновків ми дійшли під час роботи над створенням децентралізованих цифрових ідентичностей – проектом, покликаним розширити можливості людства, створити в суспільстві культуру довіри, запобігти зловживанням персональною інформацією, подарувати кожній людині повний контроль над нею та зробити ідентифікацію зручнішою.

1. Кожна людина повинна мати контроль над своєю цифровою ідентичністю. Зараз у світі існують мільйони служб і програм, які збирають, зберігають і використовують наші дані. І ми ніяк не можемо на це вплинути, крім того першого моменту, коли ми надаємо програмі дозвіл обробляти наші дані. У світі, де порушення інформаційної безпеки та викрадення ідентифікаційних даних стають дедалі частішими та підступнішими, така ситуація неприйнятна. Потрібно, щоб користувачі могли самі керувати своїми ідентичностями. Тож ми розглянули різні нові стандарти, децентралізовані системи зберігання даних, протоколи консенсусу й ланцюжки блоків транзакцій і дійшли висновку, що остання технологія та її протоколи стануть найкращою базою для децентралізованих ідентичностей.
2. Ідентичності мають насамперед бути конфіденційними.
   Зараз багатьом програмам, службам і організаціям потрібно контролювати дані наших ідентичностей, щоб надавати нам зручні, прогнозовані та персоналізовані послуги. Необхідна альтернатива – безпечні цифрові центри, де в зашифрованому вигляді зберігатимуться дані користувачів (центри ідентичностей). Така альтернатива забезпечить службам і програмам взаємодію з цими даними й водночас запропонує користувачам контроль над персональними даними та їх конфіденційність.
3. Довіра – це особистий здобуток кожної людини та культура, що плекається в суспільстві.
   Традиційні системи ідентифікації спрямовано переважно на автентифікацію та керування доступом. Але система самостійного керування ідентичностями вимагатиме й орієнтації на інші пріоритети – щирість і довіру. У децентралізованих системах довіра базується на засвідченнях, тобто заявах про ідентичність користувача, які підтверджують інші сутності.
4. Найголовнішим пріоритетом під час створення програм і служб має бути зручність і безпека користувача.
   Багато найпопулярніших сучасних програм і служб досягли успіху завдяки високому рівню персоналізації, для якої вони використовують особисті дані користувачів. Але децентралізовані ідентичності та центри керування ними можуть забезпечити розробникам доступ до точніших засвідчень і водночас знизити ризики порушення законів або нормативних вимог – адже служби й програми лише оброблятимуть особисті дані, а не контролюватимуть їх замість користувача.
5. Для керування ідентичностями потрібно використовувати відкриту платформу, сумісну з усіма популярними технологіями.
   Щоб нова екосистема децентралізованих ідентичностей була стабільною, надійною та доступною для всіх людей світу, вона має працювати на базі відкритих стандартних технологій, протоколів і еталонних реалізацій. Минулого року ми разом з іншими учасниками Фонду децентралізованих ідентичностей (Decentralized Identity Foundation, DIF) провели велику роботу зі створення наступних ключових компонентів.
   

• Decentralized Identifiers (DIDs) – специфікація консорціуму W3C, яка визначає стандартний формат документів з описом стану децентралізованих ідентифікаторів.
  
• Identity Hubs – сховище зашифрованих даних ідентичностей, яке включає функції ретрансляції повідомлень і намірів, обробки засвідчень, а також кінцеві точки обчислень (свої для кожної ідентичності).
  
• Universal Resolver – сервер, який зіставляє децентралізовані ідентичності в ланцюжках блоків транзакцій.
  
• Verifiable Credentials Data Model – специфікація консорціуму W3C, яка визначає стандартний формат кодування засвідчень на основі децентралізованих ідентичностей.
  

6. Нова технологія має бути придатною для роботи у світовому масштабі.
   Базова технологія, на основі якої працюватимуть децентралізовані ідентичності, має забезпечувати масштабування й ефективність на рівні звичних нам систем, оскільки з нею матимуть справу безліч користувачів, організацій і пристроїв. Деякі загальнодоступні ланцюжки блоків транзакцій: Bitcoin (BTC), Ethereum, Litecoin тощо – можуть стати надійною платформою для зберігання децентралізованих ідентичностей, записування операцій в інфраструктурі розподілених відкритих ключів і прив’язки засвідчень. Деякі спільноти, зосереджені навколо використання ланцюжків блоків транзакцій, підвищують виробничу спроможність ланцюжків з обробки транзакцій (наприклад, збільшують розмір блоків), однак загалом цей підхід знижує децентралізацію мережі та не дає досягти потенційної швидкості в мільйони транзакцій на секунду у світовому масштабі. Щоб подолати цей технічний бар’єр, ми разом із нашими партнерами працюємо над децентралізованими протоколами другого рівня, які виконуватимуться над цими загальнодоступними ланцюжками блоків транзакцій. Так ми плануємо забезпечити можливість використання нового типу ідентичностей у всьому світі й водночас зберегти їх ефективність і децентралізованість.
   
7. Децентралізовані ідентичності мають бути доступні для всіх.
   Зараз ланцюжками блоків транзакцій користуються переважно спеціалісти-ентузіасти, які готові витрачати зайвий час і сили на керування ключами та захист пристроїв. Звичайні люди на таке не погодяться, тому ми маємо зробити основні завдання з керування ідентичностями (відновлення, ротацію, захищений доступ тощо) простими, зрозумілими та безпечними.
   

Чого чекати в майбутньому

У теорії нові системи й масштабні ідеї часто виглядають дуже струнко, переконливо та заманливо. Але коли розробники й інженери беруться до реалізації проекту, на них завжди чекає багато відкриттів і несподіваних поворотів.

Зараз нашою програмою для ідентифікації Microsoft Authenticator щодня користуються мільйони людей. Надалі ми плануємо запровадити в ній підтримку децентралізованих ідентичностей і протестувати роботу нової функції. Зі згоди користувача Microsoft Authenticator зможе виступати його агентом із керування даними ідентичності та криптографічними ключами. Водночас в ланцюжку міститиметься тільки ідентифікатор: дані ідентичності, зашифровані за допомогою цих ключів, зберігатимуться в окремому центрі, недоступному для корпорації Майкрософт.

Коли ми додамо цю можливість, програми та служби зможуть взаємодіяти з даними користувачів за допомогою спільного каналу обміну повідомленнями, попередньо запитуючи дозвіл на конкретні дії з інформацією. Спочатку ми підтримуватимемо тільки невелику групу вибраних реалізацій децентралізованих ідентичностей у ланцюжках блоків транзакцій. Найімовірніше, надалі їх кількість зростатиме.

Що далі

Ми усвідомлюємо, що взялися за дуже велику й важливу справу. І хоча кожен із нас палає ентузіазмом, самі ми з нею не впораємося. Тож ми покладаємося на підтримку та внески наших партнерів за альянсом, учасників Фонду децентралізованих ідентичностей, а також усіх причетних до роботи корпорації Майкрософт: проектувальників, укладальників політик, бізнес-партнерів, розробників апаратного та програмного забезпечення. А найголовніше – ми покладаємося на вас, наших клієнтів, і ваші відгуки та пропозиції щодо перших версій наших розробок.

Це був перший допис про роботу над децентралізованими ідентичностями. У подальших матеріалах читайте про обґрунтування наших концепцій і технічні відомості про перелічені вище ключові моменти.

Сподіваємося, що ви приєднаєтеся до нас у цьому починанні!

Ключові ресурси:

• @AzureAD – профіль із нашими новинами у Twitter
  
• Сайт Фонду децентралізованих ідентичностей (DIF)
  
• Група на сайті консорціуму W3C, присвячена обліковим даним
  

З повагою,

Анкур Патель (@_AnkurPatel),

головний адміністратор проекту,

відділення технологій ідентифікації, корпорація Майкрософт

The post Децентралізовані цифрові ідентичності та ланцюжки блоків транзакцій: майбутнє, яким ми його бачимо appeared first on Microsoft 365 Blog.

За останні роки хмарні служби неодноразово ставали мішенню для зловмисників. У нас часто питають, як саме ми захищаємо особисті дані клієнтів. Тому в сьогоднішньому блозі я детально розповім, як ми слідкуємо за безпекою клієнтської інформації в Azure AD.

Захист служби та центру обробки даних

Почнімо з наших центрів обробки даних. По-перше, ми ретельно перевіряємо біографії всіх, хто працює в центрі обробки даних Microsoft. Доступ до приміщень чітко регламентовано, а кожний вхід і вихід персоналу контролюється. У цих центрах стоять стійки з критично важливими серверами Azure AD, де зберігаються дані клієнтів. Фізичний доступ до них суворо обмежений, а в приміщеннях ведеться цілодобове відеоспостереження. Крім того, коли сервер виводиться з експлуатації, усі його диски логічно й фізично знищуються, щоб уникнути витоку даних.

Доступ до служб Azure AD має обмежене коло працівників – і навіть вони повинні щодня отримувати спеціальні права на підключення до системи. Щоб підтвердити особу та відправити запит, їм потрібно пройти багатофакторну автентифікацію за допомогою смарт-карти. Щойно запит схвалено, користувач отримує потрібні права на обмежений час. Коли час сплине, права автоматично скасовуються, а щоб продовжити роботу, потрібно пройти всю процедуру спочатку.

Отримавши права, користувач підключається до системи з керованої робочої станції адміністратора (відповідно до інструкцій щодо привілейованого доступу з робочої станції). Ця процедура вимагаються політикою, і її дотримання ретельно відстежується. На робочих станціях використовується фіксований образ, а все програмне забезпечення повністю кероване. Щоб звести до мінімуму можливі ризики, на станції доступний лише обмежений набір дій. Користувач не зможе випадково обійти обмеження робочої станції адміністратора, оскільки не має адміністративних прав. Для додаткового захисту доступ до робочих станцій можна отримати лише за смарт-картами, які видаються обмеженому колу користувачів.

Нарешті, у нас є кілька (менше п’яти) “аварійних” облікових записів. Вони використовуються лише в надзвичайних ситуаціях і захищені багатоетапними “аварійними” процедурами. Робота з цими обліковими записами суворо відстежується, а після кожного входу в них система генерує оповіщення.

Виявлення загроз

Ми регулярно – кожні кілька хвилин – проводимо ряд автоматичних перевірок, щоб переконатися, що все працює як слід, навіть коли додаємо нові функції для клієнтів.

• Виявлення порушень безпеки. Ми перевіряємо систему на наявність сценаріїв, які можуть свідчити про порушення безпеки. Набір сценаріїв регулярно поповнюється. У нас навіть є автоматизовані тести, які запускають ці сценарії, щоб перевірити, чи правильно працює логіка виявлення порушень.
  
• Тестові атаки. Їх ми проводимо постійно. Під час тестових атак робиться все можливе, щоб порушити конфіденційність служби. Якщо якась з атак завершиться вдало, ми зможемо миттєво визначити вразливість у захисті та виправити її.
  
• Аудит. Усі адміністративні операції реєструються в журналі. Усі незвичні дії (наприклад, коли адміністратор створює обліковий запис із правами) генерують оповіщення, які ми ретельно вивчаємо.
  

Ми казали, що шифруємо всі ваші дані в Azure AD? Так і є. Усі ідентифікаційні дані, що зберігаються в Azure AD, шифруються за допомогою BitLocker. А як щодо операцій? Вони теж шифруються! Усі API в Azure AD працюють на базі веб-ресурсів і використовують SSL через HTTPS для шифрування даних. На всіх серверах Azure AD налаштовано TLS 1.2. Для підтримки зовнішніх клієнтів ми дозволяємо вхідні з’єднання через TLS 1.1 і 1.0. Будь-які з’єднання через застарілі версії SSL, зокрема SSL 3.0 і 2.0, блокуються. Доступ до інформації обмежений авторизацією на основі маркерів, а дані кожного клієнта доступні тільки для дозволених у ньому облікових записів. Крім того, на наших внутрішніх API додано вимогу використовувати SSL-автентифікацію клієнт-сервер на базі довірених сертифікатів і ланцюжків видавання.

Прикінцеве слово

Azure AD можна отримати двома способами. Описані тут методи захисту та шифрування стосуються загальнодоступної версії служби, яка надається та керується корпорацією Майкрософт. Якщо вас цікавить захист в National Cloud копій служби, якими керують наші довірені партнери, звертайтеся до команд, що обслуговують ваші облікові записи.

Примітка. Запам’ятайте просте правило: якщо URL-адреса сторінки, на якій ви працюєте з онлайн-службами Microsoft, закінчуються на .com, дізнатися, як захищаються та шифруються ваші дані, можна у цьому дописі.

Безпека ваших даних – наш головний пріоритет, і ми ставимося до неї ДУЖЕ серйозно. Сподіваюся, що цей огляд був корисним, а ви, знаючи, як шифруються та захищаються ваші дані, будете спокійні за свою інформацію.

З повагою,

Aлекс Сімонс (Twitter: @Alex_A_Simons),

начальник відділу керування програмами,

відділення технологій ідентифікації, корпорація Майкрософт

[Остання редакція від 03.10.17: додано інформацію про використання різних версій протоколів TLS і SSL.]

The post Як ми захищаємо ваші дані в Azure AD appeared first on Microsoft 365 Blog.