Как реализовать «железные» ключи для доступа к сайту?
Наконец, мы понемногу налаживаем удобную работу вне офиса.
Документооборот и рабочие расписания у нас "бегают" через 1С. И вот, значит, через Apache мы опубликовали нашу 1С в инет.
Всё, вроде, нормально и сравнительно безопасно.
Но что-то мне неспокойно - пользователи и в пределах офиса пароли друг другу дают, а тут "сам Бог велел" - не разберёшься же сходу что к чему.
Рано или поздно кто-то пароль напишет на бумажке, а бумажку потеряет. И ладно, если с безопасностью внутри 1С всё в порядке. Но это по идее может быть и менеджер, который допущен много к какому "грязному белью".
Короче, хочу подумать на тему "железных ключей".
Крипто-Про и прочее не советуйте, ладно? Денег немалых стоит, для эксперимента мне оные не дадут.
Подскажите ли что-то типа проверки, например, на некий файл на флешке? Или на ID флешки? Или ещё на что-то, что можно считать "железным". Ессно, хочется, чтобы это управлялось - хотя бы списком ID где-то в скриптике.
В общем-то подошёл бы и простой сертификат, который надо куда-то прописать на компе. Которых можно объявить невалидным. Но совсем не знаю как на самом деле это делается.
В целом - не то, увы.
Либо какая-то компания пиарит своё решение - типа вы сперва ходите на нашу страничку и потом, если авторизуетесь с помощью мобильника - перенаправление к вам. Либо просто описаны на пальцах принципы технологии.
Возможно ,я просто туповат и не понимаю, что там на самом деле всё ясно
Документооборот и рабочие расписания у нас "бегают" через 1С. И вот, значит, через Apache мы опубликовали нашу 1С в инет.
Всё, вроде, нормально и сравнительно безопасно.
Возможно ,я просто туповат и не понимаю, что там на самом деле всё ясно.
Вы можете настроить аутентификацию по сертификатам на Apache.
Сертификаты можно хранить и на флэшках.
Мануалы ищите по словам "apache client cetrificate authentication".
Таким образом без сертификата никто зайти на ваш 1С не сможет.
рекомендую гугл аутенфикатор. Эта бадья накатывается на телефон пользователя и генерит токены раз в минуту. Для каждого пользователя свой генератор, который крепится к идентификатору пользователя.
other_letter: на телефоне приложение, генерит токены которые валидны втечении минуты. При авторизации пользователя после ввода логина пароля запрашивается токен пользователя, который он должен посмотреть на своем телефоне.
Артем: сложнее. его надо сгенерировать для пользователя с учетом пользовательского идентификатора, в который можно включить небольшую соль от владельца сервиса. Затем показать qr код пользователю и все. Смысл сего действа чтобы усложнить пользователям рандомно раздавать пароли. Если пользователь намерен зловредить, отдав свой акк комуто, то с таким успехом можно и железный ключ дать в руки зловреду.
sasha: Ну да признаю, чуть сложнее, но тем не менее легко. Там можно и без QR кодов, просто около пятнадцати циферок сообщить, насколько я помню.
Насчет соли честно говоря не понял, как ее можно тут использовать.
А смысл железного в том что пользователь никак не может его скопировать.
Т,е если пользователь поделиться программным ключом, то ключ останется у него, и у того с кем он поделился.
А если ключ аппаратный, тут уже либо сам пользуешься, либо отдаешь ключ, и сам не можешь зайти в базу.
Артем: на крайняк можно явно просить телефон в руки админу и чтоб он своими руками сканил. Ну и как говорится выше, мы не защитимся от явного зловреда с гранатой в руке в виде логина и пароля к системе.
Сложный
Средний
