Симку могут менять, если она, например, неисправна или потерялась. Как быть тогда?
Варианты 3 и 4 из вполне легальных становятся основанием для вызова наряда полиции?
Или если банки сами захотят решить проблему, то начнут активно предлагать карты со встроенными OTP-генераторами или, на худой конец, криптокалькуляторы.
Спасибо, хорошо написали.
По личному опыту знаю, что самое сложное при разворачивании PKI — объяснить заказчику, что PKI это не только железки и программки, а еще и регламенты, политики, правила, документы, ответственные люди (в том числе из топ менеджмента компании). Собственно программное/аппаратное обеспечение это 10% от того, что называется PKI.
Теоретически можно использовать токен с интерфейсом micro-USB или Bluetooth.
Но мне кажется, что для подобных задач гораздо удобнее — одноразовые пароли.
Хотя приложение во многих случаях удобнее и проще, с точки зрения безопасности, аппаратный генератор одноразовых паролей более предпочтителен.
Полагаю, что HowTo по настройке ЭП в SAP был бы воспринят положительно.
Что-то вроде раскрытия этого вашего предложения: «Остается их только подключить.»
Замечу, что с точки зрения обзора ЭП статья довольно неплохая.
Очень надеюсь, что снижение конкуренции исключением иностранного софта не сильно повлияет на качество продукта.
И вообще тему с импортозамещением не очень поддерживаю
Механизмы аутентификации могут быть любыми. И от их выбора будет зависеть вероятность несанкционированного использования вашей ЭП.
Задача передачи документов не является задачей сервера подписи. Он документы не хранит, а только подписывает. А хранится документы могут, например в СЭД. Вот он то и решает задачу их передачи.
К сожалению почти любую системы можно превратить в ушатанную шестерку. Хороший пример — тот же PKI. Мало где в организациях он развернут по правилам. Администратор просто ставит MSCA и делает, что считает нужным. А ведь PKI — это по большей части регламенты/правила/инструкции. Примеры, когда разертывание PKI сопроваждалось написанием Certificate Policy/Certificate Practice Statement, организацией ключевой церемонии (Key Ceremony) с привлечением внешних аудиторов можно в РФ пересчитать по пальцам.
Тем не менее, организации, предоставляющей сервисы технически проще правильно настроить и эксплуатировать одну сущность, чем отвечать за всех пользователей.
У нас почему-то чаще решается вопрос с ответственностью, чем вопрос с потенциальными рисками. Можно конечно собрать со всех пользователей расписки с обязательствами делать то-то и не делать то-то с ключевым носителем. Но в случае с нарушением этих правил, пострадать может и организация предоставляющая сервис.
Если у вас 10000 пользователей, то я бы предпочел возить их на боинге, а не раздавать всем по кукурузнику в надежде, что они усвоили правила пользования.
Ну конечно содержимое подписываемых документов недоступно серверу подписи. Для подписи нужен только хэш. Процесс создания подписи сопровождается логом, который хранится в БД с защитой целостности.
Не важно общедоступен ли сервис или предоставляется только вам. Ключи в решении с облачной подписью должны храниться на HSM. Никто, даже сам сервер подписи, не получает сами закрытые ключи.
Безопасность типа «подключение по требованию» перестает работать в тот самый момент, когда вы подключаете смарт-карту.
Вы рассуждаете с точки зрения технически подкованного потенциального пользователя. На практике большая часть пользователей систем, требующих ЭП, не очень поддаются внушению и обучению в части правил хранения и эксплуатации смарт-карт.
С точки зрения владельца сервиса, требующего ЭП, пользователи от которых требуется самостоятельно хранить и использовать ключи на смарт-картах это бОльшая проблема, чем пользователи от которых требуется только проверка подлинности.
По поводу АКПП: возможно, неудачная аналогия.
Но, продолжая транспортные аналогии: вы же доверите свою безопасность пилоту самолета, а не предпочтете научиться управлять самостоятельно.
Конечно аналогия гипертрофированна, но я просто пытаюсь передать смысл:
Разумный человек захочет сам отвечать за свою безопасность только если он действительно способен это сделать.
Вопрос доверия — дело личное. Каждый сам должен определять кому, что и в какой ситуации доверять. Хорошо, что вы подходите к этому с таким уровнем ответственности.
Если на момент подписи сертификат просроченный, то подпись действительно должна быть невалидная.
Если же на момент подписи сертификат был валидным, то подпись тоже должна успешно проходить проверку даже после истечения срока жизни сертификата. Для этого используется штамп времени.
А то, что сегодня вы передаете закрытый ключ смарт-карте вас не пугает? А что там за софт на смарт-карте? Что за закладки? Не считаете ли вы, что таким образом вы уже отказались от своего закрытого ключа?
А еще вы доверяете какому-то стороннему софту делать что угодно с ключевой информацией на этой смарт-карте. Вас это тоже не пугает?
Для меня то, что вы пишете звучит как: «Коробка автомат? Да вы что? Как можно доверять переключение передач какой-то сторонней системе? Водители должны сами все контролировать!»
Конечно, надо доверять сервису. Так же как надо доверять УЦ. И много кому еще приходится доверять.
Вы же доверяете софту, который фактически осуществляет подпись используя ваши ключи в классическом варианте. Причем, я почти уверен, что вы даже не проверяете, что подписываете. Ведь реально подписывается хэш файла.
Тогда в чем различие доверия к сервису, осуществляющего подпись и доверия к софту делающему то же самое?
выполняется кража конфиденциальных данных онлайн-банкинга за счет внедрения на легитимные-страницы фишингового содержимого.
Что все-таки делает этот зловред: крадет конфиденциальные данные или подменяет платежки? Если крадет данные, то зачем внедрять фишинговое содержимое? Опишите, пожалуйста, подробнее.
Варианты 3 и 4 из вполне легальных становятся основанием для вызова наряда полиции?
Никакие сервисы Сбербанка не отвалились.
К слову, Банк Москвы, тоже продолжает присылать СМС с паролями.
По личному опыту знаю, что самое сложное при разворачивании PKI — объяснить заказчику, что PKI это не только железки и программки, а еще и регламенты, политики, правила, документы, ответственные люди (в том числе из топ менеджмента компании). Собственно программное/аппаратное обеспечение это 10% от того, что называется PKI.
Но мне кажется, что для подобных задач гораздо удобнее — одноразовые пароли.
Хотя приложение во многих случаях удобнее и проще, с точки зрения безопасности, аппаратный генератор одноразовых паролей более предпочтителен.
UPD. И тэги конечно удивительные.
Что-то вроде раскрытия этого вашего предложения: «Остается их только подключить.»
Замечу, что с точки зрения обзора ЭП статья довольно неплохая.
Очень надеюсь, что снижение конкуренции исключением иностранного софта не сильно повлияет на качество продукта.
И вообще тему с импортозамещением не очень поддерживаю
В моем понимании вы рассказываете не про Интернет вещей, а скорее про автоматизацию и SCADA системы.
Задача передачи документов не является задачей сервера подписи. Он документы не хранит, а только подписывает. А хранится документы могут, например в СЭД. Вот он то и решает задачу их передачи.
К сожалению почти любую системы можно превратить в ушатанную шестерку. Хороший пример — тот же PKI. Мало где в организациях он развернут по правилам. Администратор просто ставит MSCA и делает, что считает нужным. А ведь PKI — это по большей части регламенты/правила/инструкции. Примеры, когда разертывание PKI сопроваждалось написанием Certificate Policy/Certificate Practice Statement, организацией ключевой церемонии (Key Ceremony) с привлечением внешних аудиторов можно в РФ пересчитать по пальцам.
Тем не менее, организации, предоставляющей сервисы технически проще правильно настроить и эксплуатировать одну сущность, чем отвечать за всех пользователей.
У нас почему-то чаще решается вопрос с ответственностью, чем вопрос с потенциальными рисками. Можно конечно собрать со всех пользователей расписки с обязательствами делать то-то и не делать то-то с ключевым носителем. Но в случае с нарушением этих правил, пострадать может и организация предоставляющая сервис.
Если у вас 10000 пользователей, то я бы предпочел возить их на боинге, а не раздавать всем по кукурузнику в надежде, что они усвоили правила пользования.
Безопасность типа «подключение по требованию» перестает работать в тот самый момент, когда вы подключаете смарт-карту.
Вы рассуждаете с точки зрения технически подкованного потенциального пользователя. На практике большая часть пользователей систем, требующих ЭП, не очень поддаются внушению и обучению в части правил хранения и эксплуатации смарт-карт.
С точки зрения владельца сервиса, требующего ЭП, пользователи от которых требуется самостоятельно хранить и использовать ключи на смарт-картах это бОльшая проблема, чем пользователи от которых требуется только проверка подлинности.
По поводу АКПП: возможно, неудачная аналогия.
Но, продолжая транспортные аналогии: вы же доверите свою безопасность пилоту самолета, а не предпочтете научиться управлять самостоятельно.
Конечно аналогия гипертрофированна, но я просто пытаюсь передать смысл:
Разумный человек захочет сам отвечать за свою безопасность только если он действительно способен это сделать.
Вопрос доверия — дело личное. Каждый сам должен определять кому, что и в какой ситуации доверять. Хорошо, что вы подходите к этому с таким уровнем ответственности.
Если же на момент подписи сертификат был валидным, то подпись тоже должна успешно проходить проверку даже после истечения срока жизни сертификата. Для этого используется штамп времени.
А еще вы доверяете какому-то стороннему софту делать что угодно с ключевой информацией на этой смарт-карте. Вас это тоже не пугает?
Для меня то, что вы пишете звучит как: «Коробка автомат? Да вы что? Как можно доверять переключение передач какой-то сторонней системе? Водители должны сами все контролировать!»
Вы же доверяете софту, который фактически осуществляет подпись используя ваши ключи в классическом варианте. Причем, я почти уверен, что вы даже не проверяете, что подписываете. Ведь реально подписывается хэш файла.
Тогда в чем различие доверия к сервису, осуществляющего подпись и доверия к софту делающему то же самое?
Что все-таки делает этот зловред: крадет конфиденциальные данные или подменяет платежки? Если крадет данные, то зачем внедрять фишинговое содержимое? Опишите, пожалуйста, подробнее.