1) То, что компилятор добавляет в бинарный файл проверяется при динамическом тестировании. При использовании интерпретатора это сделать гораздо сложнее, т.к. в данном случае нужно будет провести динамическое тестирование для множества интерпретаторов (если конечно такое реально) и явно фиксировать перечень интерпретаторов допустимых к использованию.
2) Необходимость использования доверенных интерпретаторов обусловлено требованиями ФСТЭК. Мы ориентируемся на компетенции и экспертизу ФСТЭК России.
Не совсем понятно, почему Вы думаете, что это был единичный эпизод. Но даже если так, то, кажется, никто не может дать гарантий, что в будущем эта ситуация не повторится
что вы в этом случае делаете?
Не применяем обновления и мониторим. Когда данная ситуация исправлена пайп по обновлению автоматически проходит.
Меня интересует выбор Go вместо JavaScript с точки зрения требования верификации.
Если вы имели в виду сертификацию - то всё просто. Как и было написано в статье, для интерпретируемого языка нужен интерпретатор и при сертификации продукта нужно либо импользовать уже сертифицированный интерпретатор, либо сертифицировать его своими силами и, как можно понять: сертификация своими силами, например, движка JavaScript это очень сложная и долгая задача.
Почему в вашем случае верификация является столь жёстким требованием?
Сертифицированные сборки Аврора Центр поставляются в государственные структуры, которые требуют у продукта наличия сертификата ФСТЭК/ФСБ.
Значит ли это, что любые библиотеки на JavaScript запрещены в проекте из соображений безопасности?
Нет, если они не выполняются на стороне Аврора Центр. Например файлы для front-end'а написаны на TypeScript, но так как это статические файлы и JS выполняется на стороне клиента (браузера пользователя) - они не участвуют в сертификации продукта. Но если говорить о безопасности - все уязвимости исправляются.
Как проводится верификация в Go?
Сертификация происходит примерно так: исходный код передается в сертифицирующий орган, где он проходит проверки соответствия и если в ходе проверок не было выявлено никаких нарушений, то этот код и сборки на его основе являются сертифицированными.
Не понятно как это влияет на невозможность применить osmupdate
После того, как мы вручную выкачиваем файлы обновлений, мы запускаем прикреплённый к статье python-скрипт для валидации данных в этих обновлениях. Кажется, что с osmupdate у нас не получилось бы проверять файлы обновлений на наличие деструктивных данных после скачивания, а пришлось бы проверять целый pbf уже после его обновления, что потребовало бы куда больше времени, чем проверка небольших файлов обновлений.
pbf не совсем то же самое, что mbtiles. pdf используются в качестве исходных данных для mbtiles, которые затем передаются заказчику и могут использоваться в закрытом контуре без лишних манипуляций с postgres, а обычной заменой файла mbtiles на новый. Подобный подход к организации работы с гео-данными снимает необходимость с заказчика разворачивать Postgres там где он не нужен.
Собственно и поделки на node/go не к чему, когда есть небольшой модуль для apache.
В инфраструктуре Аврора Центр нет Apache, плюс его использование снижает гибкость в работе с mbtiles, если потребуются какие-то изменения. Поэтому мы не можем использовать его в качестве сервера для mbtiles-файлов. Но там, где есть возможность его использования - это хороший вариант.
Да и скрипты обновления самописные зачем, есть же osmupdate
Мы используем самописные скрипты, так как сами определяем какие именно обновления и каких регионов нам необходимы. У нас кастомная карта собранная из разных регионов и частей регионов. Это одна из причин, почему нам приходится кастомизировать тулчейн обновлений. Так же в файлах обновлений мы ищем нецензурную лексику или другой неприемлемый контент. Если такая тонкая работа с обновлениями не требуется, то osmupda - это отличный вариант.
Мы искали решение, которое работает с mbtiles, написано на компилируемом языке и может быть адаптировано под нашу архитектуру. По этим причинам, мы не нашли предложенное вами решение, а модифицировали mbtiles-go и стали использовать его.
Уточнили у отдела ИБ, они дали свои комментарии:
Не совсем понятно, почему Вы думаете, что это был единичный эпизод. Но даже если так, то, кажется, никто не может дать гарантий, что в будущем эта ситуация не повторится
Не применяем обновления и мониторим. Когда данная ситуация исправлена пайп по обновлению автоматически проходит.
Если вы имели в виду сертификацию - то всё просто. Как и было написано в статье, для интерпретируемого языка нужен интерпретатор и при сертификации продукта нужно либо импользовать уже сертифицированный интерпретатор, либо сертифицировать его своими силами и, как можно понять: сертификация своими силами, например, движка JavaScript это очень сложная и долгая задача.
Сертифицированные сборки Аврора Центр поставляются в государственные структуры, которые требуют у продукта наличия сертификата ФСТЭК/ФСБ.
Нет, если они не выполняются на стороне Аврора Центр. Например файлы для front-end'а написаны на TypeScript, но так как это статические файлы и JS выполняется на стороне клиента (браузера пользователя) - они не участвуют в сертификации продукта. Но если говорить о безопасности - все уязвимости исправляются.
Сертификация происходит примерно так: исходный код передается в сертифицирующий орган, где он проходит проверки соответствия и если в ходе проверок не было выявлено никаких нарушений, то этот код и сборки на его основе являются сертифицированными.
После того, как мы вручную выкачиваем файлы обновлений, мы запускаем прикреплённый к статье python-скрипт для валидации данных в этих обновлениях. Кажется, что с osmupdate у нас не получилось бы проверять файлы обновлений на наличие деструктивных данных после скачивания, а пришлось бы проверять целый pbf уже после его обновления, что потребовало бы куда больше времени, чем проверка небольших файлов обновлений.
pbf не совсем то же самое, что mbtiles. pdf используются в качестве исходных данных для mbtiles, которые затем передаются заказчику и могут использоваться в закрытом контуре без лишних манипуляций с postgres, а обычной заменой файла mbtiles на новый. Подобный подход к организации работы с гео-данными снимает необходимость с заказчика разворачивать Postgres там где он не нужен.
Собственно и поделки на node/go не к чему, когда есть небольшой модуль для apache.
В инфраструктуре Аврора Центр нет Apache, плюс его использование снижает гибкость в работе с mbtiles, если потребуются какие-то изменения. Поэтому мы не можем использовать его в качестве сервера для mbtiles-файлов. Но там, где есть возможность его использования - это хороший вариант.
Да и скрипты обновления самописные зачем, есть же osmupdate
Мы используем самописные скрипты, так как сами определяем какие именно обновления и каких регионов нам необходимы. У нас кастомная карта собранная из разных регионов и частей регионов. Это одна из причин, почему нам приходится кастомизировать тулчейн обновлений. Так же в файлах обновлений мы ищем нецензурную лексику или другой неприемлемый контент. Если такая тонкая работа с обновлениями не требуется, то osmupda - это отличный вариант.
Мы искали решение, которое работает с mbtiles, написано на компилируемом языке и может быть адаптировано под нашу архитектуру. По этим причинам, мы не нашли предложенное вами решение, а модифицировали mbtiles-go и стали использовать его.