безопасный автономный репозиторий git только для чтения для сценариев
Вот не такой лаконичный сценарий bash:
#!/bin/bash
v4dec() {
for i; do
echo $i | {
IFS=./
read a b c d e
test -z "$e" && e=32
echo -n "$((a<<24|b<<16|c<<8|d)) $((-1<<(32-e))) "
}
done
}
v4test() {
v4dec $1 $2 | {
read addr1 mask1 addr2 mask2
if (( (addr1&mask2) == (addr2&mask2) && mask1 >= mask2 )); then
echo "$1 is in network $2"
else
echo "$1 is not in network $2"
fi
}
}
v4test 10.1.2.3 10.0.0.0/8
v4test 10.1.2.0/24 10.0.0.0/8
v4test 192.168.0.1 10.0.0.0/8
v4test 10.0.0.0/7 10.0.0.0/8
Вывод:
10.1.2.3 is in network 10.0.0.0/8
10.1.2.0/24 is in network 10.0.0.0/8
192.168.0.1 is not in network 10.0.0.0/8
10.0.0.0/7 is not in network 10.0.0.0/8
Похоже, ваши настройки безопасны. Хотя хакеры всегда найдут способ, если у них будет достаточно времени. ...Не предъявляйте мне иск, если вас взломают. Это может подойти для небольшой установки. Для большой команды в крупном бизнесе это может быть менее подходящим (см. раздел «Социальная инженерия» ниже ).
В нем есть несколько хороших моментов, а также несколько моментов, над которыми стоит подумать, чтобы сделать его лучше.
Положительные моменты вашей установки
- Гитолит сам по себе легкий и достаточно хорошо используется с постоянными обновлениями. (последний коммит 23 дня назад на момент написания ). Это довольно безопасно.
- Gitolite использует сервер OpenSSH, который очень хорошо поддерживается и чрезвычайно безопасен.
- Публичные закрытые ключи (, такие как ключи SSH ), гораздо более безопасны, чем пароли
- Настройка очень проста, так что у вас меньше ошибок и дешевое решение.
Рекомендации по улучшению
Un -зашифрованные ключи
Хранение закрытых ключей в -зашифрованном виде не является совершенным, хотя и распространенным явлением. Как вы говорите, вы должны хранить их где-то. Однако это может быть проблемой при резервном копировании или серверах, которые не защищены физически. Есть варианты, которые требуют, чтобы вы вручную расшифровывали свои закрытые ключи при перезагрузке сервера. Пожалуй, самым простым из них является ssh-агент и вручную добавить к нему свой зашифрованный ключ при перезагрузке.
Усиление защиты SSH-сервера
Помните, что Gitolite работает на сервере OpenSSH. Есть ряд вещей, которые вы можете сделать, чтобы повысить безопасность самого ssh-сервера .
Вы даже можете запустить Gitolite в среде chroot .Существует множество руководств по настройке chrootс помощью OpenSSH. Помните, что для результата потребуется доступ к таким программам, как python, так что это сделает его более сложным с технической точки зрения, чем вы могли бы подумать во многих учебниках.
Социальная инженерия
Каждый системный администратор ищет технические способы проникновения хакера, но так много реальных взломов совершаются людьми .
Возможно, самым слабым местом вашего решения является управление ключами ssh. Это считается проблемой безопасности во многих компаниях . Gitolite возлагает все администрирование SSH-ключей на администратора. Это имеет некоторые важные последствия :
.- Без поддержки единого входа системные администраторы могут не знать, что им нужно закрыть доступ к этому конкретному ящику, когда кто-то уходит. Например, :если ваша команда использует этот ящик для себя, они будут уведомлены в ту минуту, когда сотрудник будет уволен?
- Соглашение об именах внутри конфигурации Gitolite не очень хорошее. Очень легко ошибиться и удалить или заменить неправильный ключ. Вам нужно придумать для себя такую структуру каталогов, которая дает абсолютно ясное представление о том, что вы делаете.
- Пользователи могут не сообщать вам о прекращении использования ключа. То, что они делают с этим ключом затем , может быть небезопасным. Другое, более крупное программное обеспечение, такое как Github Enterprise, на самом деле имеет встроенные функции для аудита SSH-ключей , отключая их массово и запрашивая у пользователей -повторное одобрение их.
Вы можете использовать gitlabи функцию ключа развертывания для CI. Эта функция также доступна для версии сообщества (ce ).
Ключи Global Shared Deploy позволяют только чтение -или чтение -запись (, если включен )доступ для настройки любого репозитория во всей установке GitLab.
Это действительно полезно для интеграции репозиториев с защищенными общими службами непрерывной интеграции (CI )или другими общими службами. Администраторы GitLab могут настроить ключ Global Shared Deploy в GitLab и добавить закрытый ключ в любые общие системы. Отдельные репозитории выбирают доступ к своему репозиторию с помощью этих ключей, когда сопровождающий проекта (или выше )авторизует ключ Global Shared Deploy для использования в своем проекте.
Глобальные общие ключи могут обеспечить более высокий уровень безопасности по сравнению с -ключами развертывания проекта, поскольку только администратор целевой интегрированной системы должен знать и настраивать закрытый ключ.
Администраторы GitLab настраивают ключи глобального развертывания в области администрирования в разделе Ключи развертывания. Убедитесь, что ключи имеют осмысленный заголовок, так как это будет основным способом для сопровождающих и владельцев проекта определить правильный ключ Global Deploy для добавления. Например, если ключ дает доступ к экземпляру SaaS CI, используйте имя этой службы в имени ключа, если это все, для чего он используется. При создании ключей Global Shared Deploy подумайте о степени детализации ключей -. Они могут быть очень узкого назначения, например, для конкретной службы, или более широкого применения для чего-то вроде «Везде, где вам нужно предоставить доступ для чтения к вашему репозиторию»..
После того как администратор GitLab добавит ключ глобального развертывания, сопровождающие и владельцы проекта смогут добавить его на странице «Настройки» > «Репозиторий», развернув раздел «Ключи развертывания» и нажав «Включить» рядом с соответствующим ключом, указанным в разделе «Открытые ключи развертывания, доступные для любого проекта».
https://docs.gitlab.com/ee/ssh/#deploy-keys
РЕДАКТИРОВАТЬ:gitea— это более легкий автономный git-сервис по сравнению с gitlab. Он имеет только статический одиночный двоичный файл без каких-либо зависимостей -, запрограммированный с помощью go (, вам нужно добавить файлы конфигурации и службу systemd или что-то подобное, конечно ). На веб-сайте есть хороший обзор его возможностей :https://docs.gitea.io/en-us/