А если три провайдера есть, но стоимость аренды столбов для протяжки кабеля для двух из них гораздо выше, чем для третьего?
А если существуют прочие административно-технические препоны, например, один провайдер прочно обосновался в этом районе, а другие не могут по разным надуманным причинам получить разрешение на прокладку "последней мили"?
Одним из отвращающих факторов является отсутствие сопровождения продукта или его недостаточный уровень.
За примерами ходить далеко не надо:
Многие наверняка пробовали получить техподдержку на каком-то госпортале. Поделитесь примерами дружественного доброжелательного взаимодействия.
На портале Роструда примерно год назад были какие-то проблемы. Народ на даунрадаре матерился и ругался нехорошими словами. ТП на обращения не реагировала. Просто игнорировала обращения. Дня через три неохотно признали, что есть проблема и они с этим работают. Еще через пару дней кое-как заработало. А сколько за это время организаций не сумели вовремя подать отчеты?
Несколько лет назад в ФГИС Росаккредитации возникли проблемы - путались документы разных аккредитованных лабораторий (но принадлежащих одной организации). Обращение в ТП висело примерно месяц, после чего поступала отписка, что проблема решена (на самом деле - нет). И так три раза!!!. В конце концов пришлось рявкнуть почти матом и направить в их приемную официальное письмо с большой круглой печатью, что ТП мышей не ловит и требуем немедленно их оштрафовать, уволить и расстрелять в любом порядке. Только тогда зашевелились и за пару недель всё сделали.
У Росстата есть приложуха для заполнения форм статотчетности. Требуемые шаблоны можно подгрузить в приложение прямо из него с хранилища территориального органа РС. Ан нет - нельзя. О! Опять можно! Всё! Нельзя окончательно. Приходится искать самому, скачивать и устанавливать вручную.
Ну и постоянные мелкие проблемы, которые лечатся "очисткой кэша и удалением куков", просто реально задалбывают.
С "железом" тоже не радужно:
Вот на днях появилась инфа, что iRU выпустила дешевые бюджетные платы под процессоры Intel и AMD. А что есть на офсайте?
Есть описание, какие это замечательные и прекрасные материнки.
А чего нет?
Нет вменяемой спецификации.
Нет выложенных прошивок BIOS.
Нет драйверов под чипсет и прочие шалабухи.
Нет списков поддерживаемых процессоров, планок памяти, HDD/SSD и пр.
Таким образом, приобретение такой материнки может превратиться в увлекательный квест "А как заставить это работать?"
А всё потому что гранты, инвестиции и финансирование получают на разработку продукта, но не на работу с пользователями, не на доработку и сопровождение.
"Системный администратор выключил автоматические обновления, чтобы серверы не перезагружались посреди дня."
А нафуа?
Средствами GPO можно настроить расписание установки обновлений. А так же задать диапазон времени для перезагрузки.
Если управления GPO через DC нет, то, кажется м локальными политиками можно достаточно тонко настроить. Или пошаманить со скриптами, включающую службу BITS в определенное время и отключающую после перезагрузки.
Так, прекращение работы приложения - это не причина невозможности управления домофонами, а следствие. Вернее, это явления одного порядка.
Прежде всего разорвалась связь домофонов с облачными серверами. И приложений с облачными серверами. Потому что сервера лежали под DDoS.
А открыть при помощи электронного ключа можно было по простой причине: домофон, как и большинство СКУД-терминалов, имеет кэш. Т.е. ему не обязательно каждый раз обращаться к серверам, чтобы проверить корректность ключа. Т.к. ключами пользовались не все, то кэш не переполнялся и не сбрасывался.
А зачем смарту для NFC подключение к провайдеру по Wi-Fi?
Это домофон должен быть подключен к определенному провайдеру. А по Wi-Fi или по шнурку - без разницы.
Сейчас даже многие платежные системы позволяют смартом расплачиваться без доступа к Интернету и даже без доступа к сотовому оператору. Но не Мир-пэй. Там требуется постоянная проверка токенов. Так что, в момент оплаты они могут потребовать актуализацию.
Возможно, что инфраструктура разбита на сайты доступности. И подключение к облачным серверам возможно только с конкретных IP конкретного провайдера. Как раз с целью недопущения конкурентов.
Вот сначала делают всё возможное, чтобы сократить число провайдеров (а мелких - совсем убить), а потом начинают рвать волосы на ж..., что нет резервирования.
А при чем тут кластер и то, на чьей стороне проверяется сертификат?
ВасяПупкин при том, что в централизованной системе априори полагается доверие к серверу аутотентификации. Во-первых, что он ошибочно не позволит кому либо аутентифицироваться под чужим логином, Во-вторых, что БД хешей паролей достаточно защищена, а сами хеши криптостойки.
Как достичь такого же уровня доверия (и возможно ли это в принципе) в децентрализованной пиринговой сети - вот в чем вопрос.
Задача решается простая - полностью ликвидируется доступ к несоленому хешу, чтобы исключить атаку повторением.
А я откуда знаю? Разумеется, он находится не на кластере обработчиков запросов, а где-то глубже в сети.
Но у них централизованная сеть. Т.е. регистрацией и аутентификацией занимается некий единственный центр, а не размазано это по всей пиринговой сети.
Как это нет? Вы прошли регистрацию, зарегистрировали пользователя ВасяПупкин. Возможно, привязали почту, телефон, включили двухфакторную аутентификацию. Теперь, при вводе логина/пароля система будет знать, что в нее входит подтвержденный пользователь (не физлицо, а владелец аккаунта) ВасяПупкин.
Т.е. данные для аутентификации где-то хранятся и где-то обрабатываются и подтверждаются. Но как сделать это в открытых пиринговых сетях, где централизованной регистрации нет, а децентрализованное хранение опасно, как его не защищай?
Кстати, пришла такая идея в голову по поводу централизованного хранения хешей паролей:
Хеши хранятся на отдельном сервере, куда нет прямого доступа пользователя. Т.е. запросы принимаются только от backend-серверов и не напрямую к СУБД, а через некоторое API.
При попытке подключения пользователя на этом отдельном сервере создается идентификатор неоткрытой сессии, являющийся одновременно "солью" с ограниченным временем годности".
Пользователь хеширует пароль, приписывает соль, снова хеширует. Передает логин, соль и дважды хешированный пароль.
Всё это передается на сервер аутентификации. Если соль еще не протухла (идентификатор неоткрытой сессии не исчерпал срок действия), тот по логину находит хеш пароля, приписывает соль, хеширует и сравнивает с тем, что пришло. И выдаёт либо отлуп, либо сессионный билет.
Таким образом, несоленый хеш никогда не покидает сервер аутентификации. Исключение - запись его в ходе регистрации. Но это уже другая история, не связанная с хранением хешей паролей.
Осталось решить вопрос, как защитить сессионный билет при работе по HTTP.
У Хабра кластера, похоже, нет - мелковат будет. Хотя, одна точка входа еще не гарантирует, что за ней нет распараллеливания потоков на несколько веб серверов (хотя, при одном входе это почти бессмысленно).
А вот Яндекс, Мэйл.ру, Амазон, Гугл и другие гиганты имеют из 2-3-4 точки входа на сайты. У Гугла их, как минимум, 6.
Это делается как для балансировки нагрузки, так и для повышения отказоустойчивости.
Эта обработка (выполняется даже быстрее) по большей части возлагается на кластер специально обученных серверов. Клиент только генерит сеансовый ключ и шифрует его переданным сервером открытым ключом.
В случае пиринговой сети уже каждому клиенту придется постоянно и шифровать и расшифровывать сообщения. А клиенты бывают разные!
Не нашел цифр по шифрованию AES-ключа, но проверка ЭЦП на 64-битном XEOM 3,1 GHz занимает от 100000 до 10000000 тактов процессора. Что существенно.
Думаю, слабые клиенты будут не рады.
P.S. А еще есть такая штука, как распространение новых ключей взамен протухших.
Грядет эпическое противостояние "Машина" vs "Самаритянин".
А если в данном районе нет трёх провайдеров?
А если три провайдера есть, но стоимость аренды столбов для протяжки кабеля для двух из них гораздо выше, чем для третьего?
А если существуют прочие административно-технические препоны, например, один провайдер прочно обосновался в этом районе, а другие не могут по разным надуманным причинам получить разрешение на прокладку "последней мили"?
И еще много всяких "если".
Одним из отвращающих факторов является отсутствие сопровождения продукта или его недостаточный уровень.
За примерами ходить далеко не надо:
Многие наверняка пробовали получить техподдержку на каком-то госпортале. Поделитесь примерами дружественного доброжелательного взаимодействия.
На портале Роструда примерно год назад были какие-то проблемы. Народ на даунрадаре матерился и ругался нехорошими словами. ТП на обращения не реагировала. Просто игнорировала обращения. Дня через три неохотно признали, что есть проблема и они с этим работают. Еще через пару дней кое-как заработало. А сколько за это время организаций не сумели вовремя подать отчеты?
Несколько лет назад в ФГИС Росаккредитации возникли проблемы - путались документы разных аккредитованных лабораторий (но принадлежащих одной организации). Обращение в ТП висело примерно месяц, после чего поступала отписка, что проблема решена (на самом деле - нет). И так три раза!!!. В конце концов пришлось рявкнуть почти матом и направить в их приемную официальное письмо с большой круглой печатью, что ТП мышей не ловит и требуем немедленно их оштрафовать, уволить и расстрелять в любом порядке. Только тогда зашевелились и за пару недель всё сделали.
У Росстата есть приложуха для заполнения форм статотчетности. Требуемые шаблоны можно подгрузить в приложение прямо из него с хранилища территориального органа РС. Ан нет - нельзя. О! Опять можно! Всё! Нельзя окончательно. Приходится искать самому, скачивать и устанавливать вручную.
Ну и постоянные мелкие проблемы, которые лечатся "очисткой кэша и удалением куков", просто реально задалбывают.
С "железом" тоже не радужно:
Вот на днях появилась инфа, что iRU выпустила дешевые бюджетные платы под процессоры Intel и AMD. А что есть на офсайте?
Есть описание, какие это замечательные и прекрасные материнки.
А чего нет?
Нет вменяемой спецификации.
Нет выложенных прошивок BIOS.
Нет драйверов под чипсет и прочие шалабухи.
Нет списков поддерживаемых процессоров, планок памяти, HDD/SSD и пр.
Таким образом, приобретение такой материнки может превратиться в увлекательный квест "А как заставить это работать?"
А всё потому что гранты, инвестиции и финансирование получают на разработку продукта, но не на работу с пользователями, не на доработку и сопровождение.
Два физических сервера. Один сисадмин.
Какой еще ИБэшник? Контора, судя по всему, не крупная. Бюджетом штатная единица не предусмотрена.
Но вот внешний аудит раз в год заказать могли бы.
Ох, уж эти сказочки! Ох, уж эти сказочники!
"Системный администратор выключил автоматические обновления, чтобы серверы не перезагружались посреди дня."
А нафуа?
Средствами GPO можно настроить расписание установки обновлений. А так же задать диапазон времени для перезагрузки.
Если управления GPO через DC нет, то, кажется м локальными политиками можно достаточно тонко настроить. Или пошаманить со скриптами, включающую службу BITS в определенное время и отключающую после перезагрузки.
В общем, решения есть на любой вкус.
Какой сисвдмин, такой и результат.
Скоро на сушу попрут.
Так, прекращение работы приложения - это не причина невозможности управления домофонами, а следствие. Вернее, это явления одного порядка.
Прежде всего разорвалась связь домофонов с облачными серверами. И приложений с облачными серверами. Потому что сервера лежали под DDoS.
А открыть при помощи электронного ключа можно было по простой причине: домофон, как и большинство СКУД-терминалов, имеет кэш. Т.е. ему не обязательно каждый раз обращаться к серверам, чтобы проверить корректность ключа. Т.к. ключами пользовались не все, то кэш не переполнялся и не сбрасывался.
А при чем тут приложение "Домофон ПИК", транслирующее видео с домофона на смартфон хозяина квартиры через облачные сервера?
При этом, звонящий по домофону (обычным кнопочным набором) вообще телефон иметь не обязан.
И где домофон и где шлагбаум? Радиус действия сигнала NFC - до 10 см. Так что, для управления шлагбаумом, тем более со смарта, он вряд ли пригоден.
А зачем смарту для NFC подключение к провайдеру по Wi-Fi?
Это домофон должен быть подключен к определенному провайдеру. А по Wi-Fi или по шнурку - без разницы.
Сейчас даже многие платежные системы позволяют смартом расплачиваться без доступа к Интернету и даже без доступа к сотовому оператору. Но не Мир-пэй. Там требуется постоянная проверка токенов. Так что, в момент оплаты они могут потребовать актуализацию.
Возможно, что инфраструктура разбита на сайты доступности. И подключение к облачным серверам возможно только с конкретных IP конкретного провайдера. Как раз с целью недопущения конкурентов.
А другую вселенную руки Мантрида успешно переработали.
Это яйца инопланетных форм. Вот будет веселуха, когда пробирки на Земле откроют.
Вот сначала делают всё возможное, чтобы сократить число провайдеров (а мелких - совсем убить), а потом начинают рвать волосы на ж..., что нет резервирования.
Совсем страх и совесть потеряли.
Я у себя недавно менял брелоки. Вместе с записью информации - 1000р. А раньше было вообще 500.
Домофоны не странные. Скорее всего, они могут работать и по NFC через облако и от ключа - магнитного, брелока Em-Marine или "таблетки" RW1990.
Но жильцы же умные! Зачем им покупать брелоки или что там используется, если и от смартика всё работает?
А при чем тут кластер и то, на чьей стороне проверяется сертификат?
ВасяПупкин при том, что в централизованной системе априори полагается доверие к серверу аутотентификации. Во-первых, что он ошибочно не позволит кому либо аутентифицироваться под чужим логином, Во-вторых, что БД хешей паролей достаточно защищена, а сами хеши криптостойки.
Как достичь такого же уровня доверия (и возможно ли это в принципе) в децентрализованной пиринговой сети - вот в чем вопрос.
Задача решается простая - полностью ликвидируется доступ к несоленому хешу, чтобы исключить атаку повторением.
А я откуда знаю? Разумеется, он находится не на кластере обработчиков запросов, а где-то глубже в сети.
Но у них централизованная сеть. Т.е. регистрацией и аутентификацией занимается некий единственный центр, а не размазано это по всей пиринговой сети.
Как это нет? Вы прошли регистрацию, зарегистрировали пользователя ВасяПупкин. Возможно, привязали почту, телефон, включили двухфакторную аутентификацию. Теперь, при вводе логина/пароля система будет знать, что в нее входит подтвержденный пользователь (не физлицо, а владелец аккаунта) ВасяПупкин.
Т.е. данные для аутентификации где-то хранятся и где-то обрабатываются и подтверждаются. Но как сделать это в открытых пиринговых сетях, где централизованной регистрации нет, а децентрализованное хранение опасно, как его не защищай?
Кстати, пришла такая идея в голову по поводу централизованного хранения хешей паролей:
Хеши хранятся на отдельном сервере, куда нет прямого доступа пользователя. Т.е. запросы принимаются только от backend-серверов и не напрямую к СУБД, а через некоторое API.
При попытке подключения пользователя на этом отдельном сервере создается идентификатор неоткрытой сессии, являющийся одновременно "солью" с ограниченным временем годности".
Пользователь хеширует пароль, приписывает соль, снова хеширует. Передает логин, соль и дважды хешированный пароль.
Всё это передается на сервер аутентификации. Если соль еще не протухла (идентификатор неоткрытой сессии не исчерпал срок действия), тот по логину находит хеш пароля, приписывает соль, хеширует и сравнивает с тем, что пришло. И выдаёт либо отлуп, либо сессионный билет.
Таким образом, несоленый хеш никогда не покидает сервер аутентификации. Исключение - запись его в ходе регистрации. Но это уже другая история, не связанная с хранением хешей паролей.
Осталось решить вопрос, как защитить сессионный билет при работе по HTTP.
У Хабра кластера, похоже, нет - мелковат будет. Хотя, одна точка входа еще не гарантирует, что за ней нет распараллеливания потоков на несколько веб серверов (хотя, при одном входе это почти бессмысленно).
А вот Яндекс, Мэйл.ру, Амазон, Гугл и другие гиганты имеют из 2-3-4 точки входа на сайты. У Гугла их, как минимум, 6.
Это делается как для балансировки нагрузки, так и для повышения отказоустойчивости.
Не сойдутся подписи с кем?
Мы же не знаем публичного ключа Боба заранее. И если кто-то нам подсунет фейковый адрес и публичный ключ, мы поверим ему.
Эта обработка (выполняется даже быстрее) по большей части возлагается на кластер специально обученных серверов. Клиент только генерит сеансовый ключ и шифрует его переданным сервером открытым ключом.
В случае пиринговой сети уже каждому клиенту придется постоянно и шифровать и расшифровывать сообщения. А клиенты бывают разные!
Не нашел цифр по шифрованию AES-ключа, но проверка ЭЦП на 64-битном XEOM 3,1 GHz занимает от 100000 до 10000000 тактов процессора. Что существенно.
Думаю, слабые клиенты будут не рады.
P.S. А еще есть такая штука, как распространение новых ключей взамен протухших.