Более безопасная альтернатива использованию .smbcredentials

At. На работе мы используем сервер для нашей рабочей группы, где у всех нас есть свои собственные учетные записи. У нас также есть хранилище от учреждения, частью которого является наша группа. Таким образом, хранилище каждого монтируется в файле / etc / fstab , например,

//external/storage /mounting/point cifs noperm,cred=/home/user/.smbcredentials,domain=WORK,iocharset=utf8,vers=3.0,sec=ntlmv2i,uid=user,gid=WORKGROUP,dir_mode=0770,file_mode=0770 0 0

, и каждый помещает свои учетные данные в свой файл /home/user/.smbcredentials , например,

user=user
password=pass

. , этот файл в текстовом формате. Права доступа правильные, поэтому только пользователь может просматривать / изменять файл, но так же sudo AFAIK. Проблема заключается в том, что пароль также - пароль к конфиденциальной информации пользователя как части организации (поэтому хранилище связано с той же учетной записью, что и конфиденциальная информация). Поэтому я опасаюсь, что если сервер или даже просто учетная запись пользователя будет взломана, это может иметь серьезные последствия, поскольку пароли доступны прямо здесь в виде простого текста.

Мой вопрос: как это можно сделать более безопасным? ? Конечно, должна быть альтернатива открытым текстовым паролям?

3
задан 27 July 2020 в 16:49

1 ответ

В настоящее время нет поддержки зашифрованных учетных данных. Из справочной страницы smbclient относительно -U и -A , которая передается за кулисами:

   -A|--authentication-file=filename
       This option allows you to specify a file from which to read the
       username and password used in the connection.
       ...
       Make certain that the permissions on the file restrict access from
       unwanted users.

   -U|--user=username[%password]
       Sets the SMB username or username and password.

       ...
       A third option is to use a credentials file which contains the
       plaintext of the username and password. This option is mainly
       provided for scripts where the admin does not wish to pass the
       credentials on the command line or via environment variables. If
       this method is used, make certain that the permissions on the file
       restrict access from unwanted users. See the -A for more details.
       ...

Это актуально даже в 20.04 в настоящее время. Вы должны использовать обычные текстовые учетные данные.


Вы заявляете, что «риск взлома учетной записи пользователя» является риском, и эти учетные данные также являются правами администратора:

Пароли, требуемые учреждением, являются едиными для всех (администратор). , почта, хранилище).

Правило № 2 ИТ-безопасности - это концепция наименьшей привилегии и разделения привилегий . Здесь вы разделяете учетную запись администратора и не администратора. У всех хороших организаций есть некоторые аспекты этого в игре , и это затем предотвращает доступ «администратора» в других системах. Доступ к хранилищу и электронной почте - это просто необходимость аудита попыток доступа или ограничения доступа кого-либо к информации.

Другая проблема заключается в том, что, если ваша система взломана, у вас есть множество других проблем , наименьших из которая является утечкой пароля для одного конкретного пользователя (которую можно исправить с помощью принудительной смены пароля в вашей системе Active Directory / LDAP).

Единственный другой способ сделать это без утечки пароля может написать оболочку вокруг монтирования, запросить учетные данные вручную, а затем выполнить команду монтирования напрямую, не раскрывая файл учетных данных или пароль. Сложность здесь заключается в том, что ее нужно вводить и выполнять вручную, что означает, что ваше автоматическое монтирование fstab не будет работать. Это также потребует специализированного доступа (или определенной записи sudoers для правильной работы), потому что вы передадите параметры монтирования, и только корень может сделать это в настоящее время во всех mount setups.

И что касается остальной части вашего комментария:

... возможно, я предлагаю, чтобы они разрешали (или, лучше, требуют) разные пароли для доступа к samba / хранилищу

... вы Я должен был обсудить это с разработчиками Samba на samba.org . Скорее всего, это запрос уже где-то в очереди, но совместимость Windows - это боль, поэтому ...

возможно, я предлагаю, чтобы они разрешали (или, лучше сказать, требовали) разные пароли для доступа к samba / storage

... вам придется обсудить это с разработчиками Samba на samba.org . Скорее всего, это запрос уже где-то в очереди, но совместимость Windows - это боль, поэтому ...

возможно, я предлагаю, чтобы они разрешали (или, лучше сказать, требовали) разные пароли для доступа к samba / storage

... вам придется обсудить это с разработчиками Samba на samba.org . Скорее всего, это запрос уже где-то в очереди, но совместимость Windows - это боль, поэтому ...

1
ответ дан 30 July 2020 в 22:02

Другие вопросы по тегам:

Похожие вопросы: