bazovaya-bezopasnost.md

description	cover	coverY
Как мы обеспечим безопасность наших учетных записей и инфраструктуры, а также вашей спокойной жизни и активов (не на уровне сети)	../.gitbook/assets/asus-rog-republic-of-gamers-cyberpunk-asus-zephyrus-wallpaper-2400x1350_50.jpg	400

👮 Базовая безопасность

Это своего рода отчет + возможно, вы будете использовать эти советы в своей практике. Но мы думаем, что пользователи должны знать, что наша команда заботится о вашей защите, чтобы предотвратить скамы, поддельные ICO, фишинговые кампании и так далее.

Подписи коммитов

Вот как это выглядит

Это скриншоты истории веток с GitHub и GitLab-там мы будем размещать весь наш код, проекты, документы и так далее. Все коммиты и любой код который будут публиковать члены команды KLYNTAR будут иметь такое обозначение которое даст понять что никакая третья сторона не сможет опубликовать ничего даже если каким то образом получит доступ к аккаунту. Тоже самое касается и самих хостинговых платформ. Хоть у нас нет повода сомневаться в GitHub(и ее владельца Microsoft в частности),но всё же операторы узлов, пользователи и все заинтересованные стороны должны быть уверенны в том что код опубликован именно разработчиками KLYNTAR.

Вы можете локально импортировать мой публичный GPG ключ(и ключи других членов команды) и проверять каждый новый pull через Apollo(команда checkrepo в CLI) или git verify-commit.Так же ниже доступны необходимые ссылки для настройки окружения. Дополнительно мы так же имеем отдельный репозиторий с другими ключами(Ed25519,постквантовый Dilithium и тд.) которые вы тоже можете использовать для необходимых проверок.

{% file src="../.gitbook/assets/VladChernenko.pubgpg" %} По ссылке https://github.com/KLYN74R/KlyntarTeamPubKeys ** доступно **** **больше публичных ключей {% endfile %}

{% hint style="info" %} По ссылке https://www.gnupg.org/gph/en/manual/x56.html можно узнать как импортировать ключи {% endhint %}

Дополнительные возможности

Мы создали отдельный репозиторий не просто так. GPG поддерживает не такое уж и большое количество алгоритмов(мы сейчас используем максимально надёжный RSA-4096 с пасс фразой с большой энтропией), да и возможности GitHub сводятся разве что к SSH & GPG. Тут недоступны мультиподписи или например постквантовые алгоритмы. Именно поэтому мы создадим что-то типа второго уровня безопасности для которого и надо этот репозиторий с ключами и отдельная команда в Apollo.

Читая предыдущий раздел вы могли задаться вопросом: "Ну ок, а если кто-то из вас забудет свой ноутбук где-то, запушит приватный ключ в какой-то публичный репозиторий или, например, кто-то из членов вашей команды обидеться и выпустит условный вайпер-коммит который украдёт мои приватные ключи и сотрёт мне всю файловую систему?". Опять таки благодаря таким дополнительным возможностям криптографии как мультиподписи мы сможем избежать подобных инцидентов. Так же не исключены кратные подписи(подпись хэша коммита несколькими ключами разных алгоритмов). Так например вы будете знать что помимо того, что коммит одобрили и подписали необходимое число членов команды, так ещё и дополнительно коммит подписан каким-либо поддерживаемым постквантовым алгоритмом.

Git и его хэши

Сейчас Git по дефолту использует SHA-1 хэши, но начиная с версии 2.29 началась экспериментальная поддержка перехода на SHA-256. Это очень важно так как по этой же ссылке присутствует имплементация и PoC атаки когда два разных файла будут генерировать тот же хэш.

Хоть это не критично страшно как кричат об этом некоторые издания, но всё же вопросы о надёжности SHA-1 уже не первый год интересуют людей нашей индустрии. Поэтому хоть и GitHub пока что выдает ошибку о приеме репозиториев с SHA-256 хэшами, всё же репозитории плагинов, сервисов и так далее которые будут распространятся вне хостинговых платформ(а значит независимы от того поддерживает ли данная платформа нововведения или нет) могут использовать SHA-256 в качестве хэш функции коммитов. Мы уже испытали и никаких проблем не возникло.

При этом можно всё так же подписывать хэш репозитория сторонними ключами и составлять свои правила приёма. Например репозиторий сервиса может быть принят нодами только если он подписан парой Ed25519 ключей создателя сервиса и самого крупного ходлера токенов сервиса или чтоб принятие репозитория поддержало более 2/3 подписей валидаторов сервиса и другие правила которые вы только можете себе сами составить.

Аккаунты

Все наши аккаунты в социальных сетях имеют MFA и свою собственную политику создания паролей. Здесь речь идёт даже не что-то отличное от rockyou.txt или разных регистров, а использование разных алфавитов, регистров, unicode символов, эмодзи, направления текста и спецсимволов. Пароли хранятся в холодных хранилищах и используются по надобности.

Разумеется мы используем разные пароли от сайта к сайту. Так же ключи для 2FA разделены между несколькими провайдерами и между разными девайсами.

Публичные данные(DNS,почты) и пути подхода

Мы знакомы с тактиками получения первоначального доступа, фишинг кампаниями и прочим. По этой причине мы контролируем историю и записи DNS для предотвращения атак по захвату поддомена, дампа зоны, спуфинга и так далее.

Вскоре мы так же подпишем нашу зону(когда там будет полноценная инфраструктура сайтов, а не парковочные страницы)

Все почты которые в публичном доступе доступны каждому сборщику информации. Например, функционал сайтов позволяет обновить пароль и таким образом раскрывает наличия email в своей базе данных. Мы и сами анализируем на каких сайтах что было использовано. К примеру, инструмент

{% embed url="https://github.com/megadose/holehe" %}

...или вот

{% embed url="https://github.com/elceef/dnstwist" %}

Мы используем и другие инструменты и ресурсы для сбора информации и стараемся покрывать максимальную область для обеспечения безопасности на всех фронтах.

Сторонние приложения и доступ к нашим аккаунтам

Мы контролируем какие сторонние сервисы и приложения имеют доступ к нашим аккаунтам. Для рабочих процессов мы используем GitGuardian, наши книги написаны с использованием GitBook.

Во всём мы стараемся давать минимальные привилегии и ограничивать уровень доступа до минимума, чтобы даже при компрометации учётки это не повлияло на наши аккаунты / инфраструктуру.

GitHub и другие сайты которые предоставляют частичный доступ позволяют грамотно оперировать возможностями для третьих сторон, чем мы и пользуемся.

Что по контрибуторах

{% hint style="info" %} Опубликуем позднее когда эти самые контрибуторы появятся🙂 {% endhint %}

А если в двух словах, то мы так же хотим чтоб и контрибуторы следовали тем же правилам которым следуем мы. Это и подпись своего кода с отдельным доказательством через блокчейн и контроль своих учётных записей и другое.

Самоподдерживающаяся безопасность с помощью симбиотов

Наверняка впервые в истории крипто проектов мы будем использовать собственную разработку для обеспечения собственной безопасности. Так симбиоты пользуясь децентрализованной природой блокчейнов(и ее максимумов в случае KLYNTAR) будут служить источником инфраструктуры публичных ключей для нас и других разработчиков.

Мы будем добавлять какую-то информацию про версии, изменения ключей и так далее в симбиоты, а вы сможете убедиться что всё надёжно.

Как тут поможет релиз Continental

Coming soon 👻

Будет опубликовано со временем

{% hint style="warning" %} Следите за обновлениями - мы обещаем ещё больше интересной информации и улучшений {% endhint %}