Полный список используемых крейтов для фронтенда и бэкенда - в конце статьи.

В листингах кода полно комментариев.

Структура репозитория

Начать следует с создания Cargo.toml в корне репозитория:

[workspace]
members = [
    "./frontend",
    "./backend",
    "./backend/migration",
    "./data_types"
]
resolver = "2"

[profile.dev]
incremental = true

[profile.release]
opt-level = 3
lto = true
panic = 'abort'

Как видно, Cargo позволяет объединить несколько подпроектов в один через рабочие пространства. Помимо бэкенда и фронтенда, виден также подпроект миграций SQL и подпроект типов данных.

Строка resolver = "2" нужна для корректного управления подпроектами.

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

Миграции SQL

В проекте используется SeaORM. Грубо говоря, это - способ управления сущностями через базу данных. Поэтому, чтобы начать разработку, нужно сперва определить типы данных, которые понадобятся для проекта.

Для этого в папке backend выполните следующие команды:

cargo install sea-orm-cli # устанавливает клиент управления миграциями

sea-orm-cli migrate init # инициализирует подпроект миграций

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

Типичный файл миграции выглядит так:

use sea_orm_migration::prelude::*;

#[derive(DeriveMigrationName)]
pub struct Migration;

#[async_trait::async_trait]
impl MigrationTrait for Migration {

  /// Эта функция выполняется при запуске миграции. Если база данных пуста,
  /// и это первая миграция, - то в ней нужно создать таблицы для хранения
  /// информации.
  async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {
    manager
      .create_table(
        Table::create()
          .table(Users::Table)
          .if_not_exists()
          .col(ColumnDef::new(Users::Id)
            .big_integer().not_null().auto_increment()
            .primary_key().unique_key()
          )
          .col(ColumnDef::new(Users::Login)
            .string().not_null().unique_key()
          )
          .col(ColumnDef::new(Users::Salt).string().not_null())
          .col(ColumnDef::new(Users::PHash).string().not_null())
          .col(ColumnDef::new(Users::Settings).string().not_null())
          .to_owned()
      ).await
  }

  /// Эта функция используется, чтобы откатить нежелательные изменения при
  /// необходимости. Грубо говоря, здесь нужно писать код, который вернёт
  /// всё, как раньше. Но не прям в 2007.
  async fn down(&self, manager: &SchemaManager) -> Result<(), DbErr> {
    manager.drop_table(Table::drop().table(Users::Table).to_owned()).await
  }
}

/// В перечислении мы определяем поля идентификаторов.
#[derive(Iden)]
enum Users {
  Table, // Да, среди полей таблицы затесалась сама таблица.
         // Подробнее: https://docs.rs/sea-query#iden
  Id,
  Login,
  Salt,
  PHash,
  Settings,
}

Миграции перечисляются в backend/migrations/lib.rs:

pub use sea_orm_migration::prelude::*;

mod m20231007_000001_create_tables; // Указываем файл с миграцией

pub struct Migrator;

#[async_trait::async_trait]
impl MigratorTrait for Migrator {
  fn migrations() -> Vec<Box<dyn MigrationTrait>> {
    vec![
    
      // И добавляем миграции сюда.
      Box::new(m20231007_000001_create_tables::Migration),
      
    ]
  }
}

Для запуска миграций вам необходимо создать пустую базу данных и из папки backend выполнить команду:

sea-orm-cli migrate -u postgres://login:pass@localhost/dbname

Затем, чтобы сгенерировать сущности, которые вы сможете использовать в коде на бэкенде, необходимо выполнить следующую команду:

sea-orm-cli generate entity -o ./src/entities

Вуаля, вы можете теперь подключить сущности через mod entities; в main.rs и использовать их примерно следующим образом:

let new_user = users::ActiveModel {
  login: ActiveValue::Set(data.login.clone()),
  salt: ActiveValue::Set(salt.clone()),
  p_hash: ActiveValue::Set(base64.encode(p_hash)),
  settings: ActiveValue::Set(serde_json::to_string(&settings)?),
  ..Default::default()
};
Users::insert(new_user).exec(db as &DbPool).await?;

Общие структуры данных

Чтобы использовать все преимущества строгой типизации в Rust, необходимо задать общие типы данных, которые планируется использовать на бэкенде и фронтенде.

Файл data_types/src/lib.rs:

use chrono::{DateTime, Utc, serde::ts_seconds};
use serde::{Serialize, Deserialize};

// Авторизация и управление аккаунтами:
#[derive(Deserialize, Serialize)]
pub struct SignUpRequestData {
  pub login: String,
  pub name: String,
  pub password: String,
}

#[derive(Deserialize, Serialize)]
pub struct SignInRequestData {
  pub login: String,
  pub password: String,
}

#[derive(Serialize, Deserialize)]
pub struct IsUserValid {
  pub valid: bool,
}

#[derive(Deserialize, Serialize)]
pub struct UserToken {
  pub user_id: i64,
  pub token_str: String,
  #[serde(with = "ts_seconds")]
  pub birth: DateTime<Utc>,
}

Чтобы использовать подпроект в бэкенде и фронтенде, укажите data_types как зависимость в их Cargo.toml:

data_types = { path = "../data_types" }

Структура бэкенда

Часть 1. Управление ошибками

Можно было бы использовать anyhow::Error или подобные крейты, но самописные решения предоставляют определённую гибкость:

use base64::DecodeError;
use bb8_redis::redis::RedisError;
use bb8_redis::bb8::RunError;
use sea_orm::DbErr;
use rocket::{
  request::Request,
  response::{self, Response, Responder},
  http::{ContentType, Status},
};
use std::{io, fmt, num::ParseIntError, string::FromUtf8Error};
use serde::{Serialize, Deserialize};
use serde_json::Error as JsonError;

/// Структура данных ошибок.
#[derive(Serialize, Deserialize, Debug)]
pub struct ErrorResponder {
  message: String,
}

/// Мы воплощаем трейт Responder, чтобы указать,
/// как Rocket будет эту ошибку возвращать клиенту.
#[rocket::async_trait]
impl<'r> Responder<'r, 'static> for ErrorResponder {
  fn respond_to(self, _: &'r Request<'_>) -> response::Result<'static> {
    let json_answer = serde_json::to_string(&self).unwrap();
    Response::build()
      .status(Status::Unauthorized)
      .header(ContentType::JSON)
      .sized_body(json_answer.len(), io::Cursor::new(json_answer))
      .ok()
  }
}

impl fmt::Display for ErrorResponder {
  fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
    write!(f, "{}", self.message)
  }
}

impl From<DbErr> for ErrorResponder {
  fn from(err: DbErr) -> ErrorResponder {
    ErrorResponder { message: err.to_string() }
  }
}

impl From<String> for ErrorResponder {
  fn from(string: String) -> ErrorResponder {
    ErrorResponder { message: string }
  }
}

impl From<&str> for ErrorResponder {
  fn from(str: &str) -> ErrorResponder {
    str.to_owned().into()
  }
}

impl From<io::Error> for ErrorResponder {
  fn from(err: io::Error) -> ErrorResponder {
    err.to_string().into()
  }
}

impl From<JsonError> for ErrorResponder {
  fn from(err: JsonError) -> ErrorResponder {
    err.to_string().into()
  }
}

impl From<ParseIntError> for ErrorResponder {
  fn from(err: ParseIntError) -> ErrorResponder {
    err.to_string().into()
  }
}

impl From<RedisError> for ErrorResponder {
  fn from(err: RedisError) -> ErrorResponder {
    err.to_string().into()
  }
}

impl From<RunError<RedisError>> for ErrorResponder {
  fn from(err: RunError<RedisError>) -> ErrorResponder {
    err.to_string().into()
  }
}

impl From<DecodeError> for ErrorResponder {
  fn from(err: DecodeError) -> ErrorResponder {
    err.to_string().into()
  }
}

impl From<FromUtf8Error> for ErrorResponder {
  fn from(value: FromUtf8Error) -> Self {
    value.to_string().into()
  }
}

/// Делаем биндинг для удобного использования в функциях.
pub type MResult<T> = Result<T, ErrorResponder>;

Использование MResult<T> облегчает нашу жизнь таким образом:

pub async fn login(...) -> MResult<Json<UserToken>> {
  let user_data = find_by_login(&data.login, db).await?;
  let phash_db = base64.decode(user_data.p_hash.as_bytes())?;
  let salted_password = data.password.clone() + &user_data.salt;
  validate_hashes(salted_password.as_bytes(), &phash_db)?;
  let utl_name = get_user_tokens_list_name(&user_data.id);
  let cacher = cacher as &RedisPool;
  let mut cacher_conn = cacher.get().await?;
  let user_tokens_list_len: isize = cacher_conn.llen(&utl_name).await?;
  let token = generate_token(user_data.id)?;
  if user_tokens_list_len >= MAX_TOKENS_PER_USER {
    cacher_conn.ltrim(&utl_name, 0, MAX_TOKENS_PER_USER - 1).await?;
  }
  cacher_conn.lpush(&utl_name, &serde_json::to_string(&token)?).await?;
  Ok(Json(token))
}

Часть 2. Управление shared-объектами

Для начала загрузим в приложение всю необходимую информацию для его работы и инициализируем объекты для управления данными:

use bb8_redis::{bb8::Pool as Bb8Pool, RedisConnectionManager};
use dotenv::dotenv;
use sea_orm::*;

pub type RedisPool = Pool<RedisConnectionManager>;
pub type DbPool = DatabaseConnection;

pub struct AppState {
  pub db_url: String,
  pub redis_url: String,
}

pub(super) async fn load_app_state() -> MResult<(AppState, DbPool, RedisPool)> {
  dotenv().ok(); // Загружаем все переменные из файла `.env` в окружение
  let state = AppState {
    db_url: std::env::var("DATABASE_URL").expect("DATABASE_URL variable must be set"),
    redis_url: std::env::var("REDIS_URL").expect("REDIS_URL variable must be set"),
  };
  let db = connect_db(&state.db_url).await?;
  let cacher = connect_redis(&state.redis_url).await?;
  Ok((state, db, cacher))
}

async fn connect_db(db_url: &str) -> MResult<DbPool> {
  Ok(Database::connect(db_url).await?)
}

async fn connect_redis(redis_url: &str) -> MResult<RedisPool> {
  let manager = RedisConnectionManager::new(redis_url)?;
  Ok(Bb8Pool::builder().build(manager).await?)
}

А теперь напишем функцию, которая полностью заменяет fn main():

#[launch]
async fn rocket() -> _ {
  // 1. Установка уровня логгирования.
  if cfg!(debug_assertions) {
    simple_logger::init_with_level(log::Level::Info).unwrap();
  } else {
    simple_logger::init_with_level(log::Level::Warn).unwrap();
  }

  // 2. Загрузка основных параметров и установка соединений с базами данных.
  let (state, db, cacher) = match load_app_state().await {
    Ok((state, db, cacher)) => (state, db, cacher),
    Err(err) => panic!("{}", err),
  };

  // 3. Запуск сервера.
  rocket::build()
    // перечисляем управляемые объекты:
    .manage(state)
    .manage(db)
    .manage(cacher)
    // перечисляем роуты
    .mount("/", routes![
      ...
    ])
}

Часть 3. Роуты

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

pub use rocket::{State, serde::json::Json};
pub use rocket::post;

/// Создаём метод POST для пути '/login',
/// который принимает `application/json` в теле запроса.
#[post("/login", format = "json", data = "<data>")]
pub async fn login(
  data: Json<SignInRequestData>, // JSON из тела запроса
  db: &State<DbPool>,
  cacher: &State<RedisPool>,
) -> MResult<Json<UserToken>> {
  ...
  Ok(Json(token))
}

Чтобы запрашивать через параметры роута ещё и ключ аутентификации, используйте следующий код:

/// Ключ API через заголовок аутентификации.
pub struct ApiToken(String);

#[rocket::async_trait]
impl<'r> FromRequest<'r> for ApiToken {
  type Error = ErrorResponder;

  async fn from_request(req: &'r Request<'_>) -> Outcome<Self, Self::Error> {
    /// Извлекаем токен из строки авторизации.
    fn extract_token(key: &str) -> String {
      key.to_owned().replace("Bearer ", "")
    }

    // Получаем текст заголовка `Authorization`:
    match req.headers().get_one("Authorization") {
      None => Outcome::Error((Status::Forbidden, "Authorization token is missing.".into())),
      Some(key) => Outcome::Success(ApiToken(extract_token(key))),
    }
  }
}

Тогда роуты принимают подобный вид:

#[get("/project/<project_id>")]
pub async fn get_project_info(
  project_id: i64, // Запрос `/project/2221` установит
                   // в переменную `project_id` значение 2221.
  db: &State<DbPool>,
  cacher: &State<RedisPool>,
  token: ApiToken, // Токен, который клиент должен передавать
                   // вместе с запросом.
) -> MResult<Json<ProjectCardInfo>> { ... }

Запуск

cd backend
cargo run --release

Структура фронтенда

Часть 1. Конфигурация приложения

Создайте Dioxus.toml с подобным содержимым:

[application]
name = "app_name"
default_platform = "web"
out_dir = "../dist"
asset_dir = "public"

[web.app]
title = "App Title"

[web.watcher]
watch_path = ["src", "public"]

[web.resource]
# Если требуется использовать TailwindCSS,
# изучите https://dioxuslabs.com/learn/0.4/cookbook/tailwind
style = ["tailwind.css"]
script = []

[web.resource.dev]
style = []
script = []

И установите dioxus-cli:

cargo install dioxus-cli

Часть 2. Облегчаем себе жизнь при работе с LocalStorage

Используем простейшие функции для получения и записи значений:

pub type MResult = Result<(), AppError>;
pub static APP_TOKEN_LOCALSTORAGE_KEY: &str = "token";

/// Чтение из локального хранилища.
pub fn get_from_storage(key: &str) -> Result<String, AppError> {
  let window = match web_sys::window() {
    None => return Err("Не удалось получить параметры окна".into()),
    Some(window) => window,
  };
  let storage = match window.local_storage() {
    Err(_) => return Err("Не удалось получить доступ к LocalStorage".into()),
    Ok(None) => return Err("LocalStorage пуст".into()),
    Ok(Some(storage)) => storage,
  };
  if let Ok(Some(value)) = storage.get_item(key) {
    Ok(value)
  } else {
    Err(format!("Не удалось получить значение по ключу \"{}\"", key).into())
  }
}

/// Запись в локальное хранилище.
pub fn put_in_storage(key: &str, val: &str) -> MResult {
  let window = match web_sys::window() {
    None => return Err("Не удалось получить параметры окна".into()),
    Some(window) => window,
  };
  let storage = match window.local_storage() {
    Err(_) => return Err("Не удалось получить доступ к LocalStorage".into()),
    Ok(None) => return Err("LocalStorage пуст".into()),
    Ok(Some(storage)) => storage,
  };
  if storage.set_item(key, val).is_err() {
    return Err("Не удалось сохранить значение в LocalStorage".into())
  }
  Ok(())
}

/// Получение заголовка авторизации.
pub fn get_authorization_token() -> Result<String, AppError> {
  get_from_storage(APP_TOKEN_LOCALSTORAGE_KEY)
}

Часть 3. Добавляем функции для запросов к серверу

pub static BASE_API_URL: &str = "schema://example.com/";
pub static LOGIN_API: &str = "login";
pub static AUTH_API: &str = "user";
pub static CHECK_USER_API: &str = "/check";

/// Осуществляет вход в аккаунт.
pub async fn login(username: String, password: String) -> MResult {
  let token: UserToken = reqwest::Client::new()
    .post(format!("{}{}", BASE_API_URL, LOGIN_API))
    .json(&SignInRequestData { login: username, password })
    .send()
    .await?
    .json::<UserToken>()
    .await?;
  put_in_storage(APP_TOKEN_LOCALSTORAGE_KEY, &serde_json::to_string(&token).unwrap())
}

/// Осуществляет проверку пользовательского токена.
pub async fn check_user_token() -> MResult {
  let res: IsUserValid = reqwest::Client::new()
    .post(format!("{}{}{}", BASE_API_URL, AUTH_API, CHECK_USER_API))
    .bearer_auth(get_authorization_token()?)
    .send()
    .await?
    .json()
    .await?;
  if !res.valid { return Err("Пользователь не авторизован".into()) }
  Ok(())
}

Часть 4. Подготовка реактивных состояний приложения

Чтобы Dioxus был способен динамически отрисовывать веб-страницу в зависимости от изменения данных, их необходимо задать заранее:

/// Структура данных, которая отвечает за отображение необходимого раздела.
#[derive(Clone, Debug, PartialEq)]
pub enum InAppLocation {
  Unset,
  Auth,
  Register,
  Projects,
  ProjectSurvey(ProjectID),
  PrepareRecommendationsByTest(ProjectID),
  // ...
}

/// Вспомогательная структура для принудительной отрисовки DOM.
#[derive(Clone, Debug, PartialEq)]
pub enum LocalUpdate {
  NotScheduled,
  Scheduled,
}

Далее мы создаём структуру данных, которую будем передавать во все компоненты приложения по необходимости:

#[derive(Copy, Clone)]
pub struct AppHooks<'a> {
  pub app_location: &'a UseState<InAppLocation>,
  pub update_scheduler: &'a UseState<LocalUpdate>,
  pub project_selected: &'a UseState<ProjectID>,
  pub get_summaries_fut: &'a UseFuture<Result<Vec<ProjectLineSummary>, AppError>>,
  pub get_project_card_fut: &'a UseFuture<Result<ProjectCardInfo, AppError>>,
  pub get_project_card_st: &'a UseState<ProjectID>,
  // ...
}

impl<'a> AppHooks<'a> {
  pub fn new(cx: Scope<'a>) -> Self {
    // Состояния приложения.
    let app_location = use_state(cx, || InAppLocation::Unset);
    let update_scheduler = use_state(cx, || LocalUpdate::NotScheduled);

    // Задание опционального хука
    let project_selected = use_state(cx, || 0);
    let get_project_card_fut = use_future(cx, (), |_| {
      let project_id = project_selected.to_owned();

      async move { get_project_info(*project_id).await }
    });

    // Задание опционального хука
    // Мы хотим, чтобы замыкание-футура выполнялась только тогда,
    // когда `get_project_survey_st` установлен в `true`.
    let get_project_survey_st = use_state(cx, || false);
    let get_project_survey_fut = use_future(cx, (), |_| {
      let survey_loaded = get_project_survey_st.to_owned();

      async move {
        if survey_loaded == true {
          let res = get_project_survey().await;
          if res.is_ok() { survey_loaded.set(true); }
          res
        } else { Err("Ожидание запроса.".into()) }
      }
    });

    // Отдаём хуки
    AppHooks {
      // Состояния
      app_location,
      update_scheduler,
      project_selected,
      // Исполняемые замыкания
      get_summaries_fut: use_future(cx, (), |_| async move { get_summaries().await }),
      get_project_card_fut,
      get_project_card_st: use_state(cx, || 0),
      // ...
    }
  }
}

Часть 5. Подготавливаем главный компонент приложения и запуск

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

fn main() { dioxus_web::launch(App); }

use dioxus::core::{Element, Scope};
use dioxus::prelude::*;

/// Главный компонент веб-приложения.
fn App(cx: Scope) -> Element {
  // Создание хранилища состояний
  let hx = AppHooks::new(cx);

  // Замыкание для проверки аутентификации
  let apploc_fut = use_future(cx, (), |_| async move { check_user_token().await });

  // Раскладка для отображения состояния загрузки
  let loading_lt = rsx!( div { "Загрузка..." });

  // Отрисовка приложения
  // Поскольку отрисовка условная, все состояния и хуки должны 
  // выноситься в безусловный блок. Следовательно, данные до компонентов
  // должны прокидываться из главного компонента.
  cx.render({

    // 1. Получение текущего местоположения
    let curr_location = (**hx.app_location).clone();

    // 2. Отрисовка страницы в соответствии с местоположением
    match curr_location {

      // Если положение не установлено -
      // сравниваем с результатом валидации токена.
      InAppLocation::Unset => {
        match apploc_fut.value() {
          Some(Ok(_)) => { hx.app_location.set(InAppLocation::Projects); },
          Some(Err(_)) => { hx.app_location.set(InAppLocation::Auth); },
          None => {},
        };
        loading_lt
      },

      // Страницы:
      InAppLocation::Auth => rsx!(Auth(cx, hx)),
      InAppLocation::Register => rsx!(Register(cx, hx.app_location)),
      InAppLocation::Projects => rsx!(Projects(cx, hx)),
      InAppLocation::ProjectSurvey(project_id) => rsx!(ProjectSurvey(cx, hx, project_id)),
      // ...
    }
  })
}

Немного пояснений:

1. После установки значений или обновления состояния замыканий-футур будет выполнен рендеринг VirtualDOM, и изменения будут при необходимости отрисованы.
2. Внутри блока cx.render({ ... }) необходимо писать код, который должен будет выполняться каждую перерисовку, а перед ним - код, который должен будет выполниться лишь один раз.
3. При этом нельзя в компонентах использовать любые хуки (функции Dioxus, которые начинаются на use_), если эти компоненты будут отрисованы условно (см. правила хуков по ссылке ниже). Например, InAppLocation::Projects будет отрисован только после того, как отрисуется Auth, и будет выполнена авторизация. Это - причина, почему хуки лучше выносить в отдельную структуру данных - AppHooks.

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

Часть 6. Компоненты

Код компонента страницы авторизации выглядит приблизительно так:

use dioxus::prelude::*;
use dioxus_html::input_data::keyboard_types::Code as KeyCode;
use log::{error, debug};

use crate::requests::auth::login;
use crate::states::{AppHooks, InAppLocation, LocalUpdate};

/// Страница авторизации пользователя.
pub fn Auth<'a>(cx: Scope<'a>, hx: AppHooks<'a>) -> Element<'a> {
  // Создаём хуки, которые будут использоваться только в этом компоненте
  let email = use_state(cx, || "".to_string());
  let password = use_state(cx, || "".to_string());
  
  // Вход в аккаунт
  // Это замыкание будет выполнено по нажатию на кнопку "Войти"
  let auth_fut = move |_| {
    cx.spawn({
      to_owned![email, password];
      let app_location = hx.app_location.to_owned();
      let update_scheduler = hx.update_scheduler.to_owned();
      async move {
        match login(
          email.current().to_string().clone(),
          password.current().to_string().clone()
        ).await {
          Ok(_) => {
            debug!("Токен получен.");
            app_location.set(InAppLocation::Projects);
            update_scheduler.set(LocalUpdate::Scheduled);
          },
          Err(e) => error!("{}", e),
        }
      }
    });
  };
  
  // Вход в аккаунт
  // Это замыкание будет выполено по нажатию на кнопку `Enter` на поле пароля
  //
  // Q: Почему нужно два одинаковых внешне замыкания?
  // A: Из-за различия в типах событий по нажатию кнопки мыши или клавиатуры.
  let auth_by_enter_fut = move |_| {
    cx.spawn({
      to_owned![email, password];
      let app_location = hx.app_location.to_owned();
      let update_scheduler = hx.update_scheduler.to_owned();
      async move {
        match login(
          email.current().to_string().clone(),
          password.current().to_string().clone()
        ).await {
          Ok(_) => {
            debug!("Токен получен.");
            app_location.set(InAppLocation::Projects);
            update_scheduler.set(LocalUpdate::Scheduled);
          },
          Err(e) => error!("{}", e),
        }
      }
    });
  };
  
  // Отрисовка страницы
  cx.render(rsx! {
    div {
      class: "flex mx-auto justify-center items-center h-screen w-2/5",
      div {
        p {
          class: "text-center font-medium mb-2",
          "Авторизация",
        },
        input {
          class: "border-b-2 w-full hover:outline-2 outline-offset-2 mb-1 rounded-sm",
          placeholder: "Электронная почта",
          r#type: "email", // Так мы можем использовать зарезервированные
                           // в языке Rust слова, которые используются в HTML.
          value: "{email}", // Значение будет соответствовать значению хука `email`.
          oninput: move |evt| email.set(evt.value.clone()),
        },
        input {
          class: "border-b-2 w-full hover:outline-2 outline-offset-2 mb-1 rounded-sm",
          r#type: "password",
          placeholder: "Пароль",
          value: "{password}",
          oninput: move |evt| password.set(evt.value.clone()),
          onkeypress: move |evt| {
            if evt.code() == KeyCode::Enter { auth_by_enter_fut(evt); }
          }
        },
        div {
          class: "flex flex-row columns-2 block gap-4",
          button {
            class: "w-full rounded-xl shadow-md px-4 py-1 text-white bg-orange-500",
            onclick: auth_fut,
            "Войти"
          },
          button {
            class: "w-full rounded-xl shadow-md px-4 py-1 text-white bg-teal-800",
            onclick: move |_| { hx.app_location.set(InAppLocation::Register); },
            "Зарегистрироваться"
          },
        },
      }
    }
  })
}

Код компонента страницы проектов:

pub fn Projects<'a>(cx: Scope<'a>, hx: AppHooks<'a>) -> Element<'a> {
  // Создание проекта
  let new_project_fut = move |_| {
    cx.spawn({
      let update_scheduler = hx.update_scheduler.clone();
      async move {
        match new_project().await {
          Ok(_) => {
            debug!("Проект создан.");
            update_scheduler.set(LocalUpdate::Scheduled);
          },
          Err(e) => error!("{}", e),
        }
      }
    });
  };

  // Отрисовка страницы
  cx.render({

    // 1. Проверка планировщика (если добавили/удалили проект)
    let curr_summaries_scheduler_state = hx.update_scheduler.clone();

    if curr_summaries_scheduler_state == LocalUpdate::Scheduled {
      hx.update_scheduler.set(LocalUpdate::NotScheduled);
      hx.get_summaries_fut.restart(); // так можно перезапускать футуры
                                      // и ожидать от них новых значений
    }

    // 2. Обновление значений из корутины
    let mut summaries_list = Vec::new();
    if hx.get_summaries_fut.value().is_some() {
      let res = hx.get_summaries_fut.value().unwrap();
      if res.is_ok() {
        let summaries_vec = res.as_ref().unwrap();
        for summary in summaries_vec {
          summaries_list.push(rsx!(ProjectLine(cx, summary.clone(), hx.update_scheduler, hx.project_selected)))
        }
      }
    }

    // 3. Отрисовка превью проекта
    let project_card = match **hx.project_selected {
      0 => None,
      _ => Some(rsx!(ProjectCard(cx, hx))),
    };

    // 4. Финальная отрисовка
    rsx!{
      SideBar {
        app_location: hx.app_location.clone()
      },
      div {
        class: "sm:pl-80 md:pl-80 lg:pl-80 pl-12 pr-12 pt-8 pb-8",
        p {
          class: "font-medium text-xl select-none pb-4",
          "Мои проекты"
        },
        summaries_list.into_iter(), // будет последовательно отрисован
                                    // список компонентов
        div {
          class: "pt-4 py-4",
          button {
            class: "animate-slide_in pl-8 pr-8 shadow-md rounded-full px-4 py-1 text-white bg-[#607a79] hover:bg-[#719190]",
            onclick: new_project_fut,
            "Начать новый проект"
          }
        },
        project_card, // отметим, что можно передавать Option<LazyNodes<..>>
      }
    }
  })
}

Сборка

Для сборки необходимо выполнить следующую команду:

dx build --release

Встраивание фронта в бэк

Добавьте следующие функции в backend/main.rs:

// Файлы для фронтенда.
#[get("/")]
async fn frontend() -> Result<NamedFile, NotFound<String>> {
  let path = Path::new("../dist/index.html");
  NamedFile::open(&path).await.map_err(|e| NotFound(e.to_string()))
}

// Если используете TailwindCSS
#[get("/tailwind.css")]
async fn get_tw_css() -> Result<NamedFile, NotFound<String>> {
  let path = Path::new("../dist/tailwind.css");
  NamedFile::open(&path).await.map_err(|e| NotFound(e.to_string()))
}

#[get("/assets/<path..>")]
async fn get_dx_app_internals(path: PathBuf) -> Option<NamedFile> {
  NamedFile::open(Path::new("../dist/assets/").join(path)).await.ok()
}

И измените функцию async fn rocket():

rocket::build()
  // перечисляем роуты
  .mount("/", routes![
    frontend, get_dx_app_internals, get_tw_css,
    // ...
  ])

Возможные проблемы

1. /favicon.ico error

Проблема с favicon.ico? Да, бывает. Измените frontend/index.html:

<head>
  <!-- ... -->
  <link rel="shortcut icon" type="image/avif" href="favicon.avif">
  <!-- ... -->
</head>

Сконвертируйте иконку в AVIF и добавьте ещё один роут в backend:

#[get("/favicon.avif")]
async fn get_favicon() -> Result<NamedFile, NotFound<String>> {
  let path = Path::new("../dist/favicon.avif");
  NamedFile::open(&path).await.map_err(|e| NotFound(e.to_string()))
}

2. Разрешение проблем с CORS

Если вы хотите на сервере разрешить CORS, добавьте следующий код:

/// Разрешает CORS.
pub struct CorsAllower;

#[rocket::async_trait]
impl Fairing for CorsAllower {
  fn info(&self) -> Info {
    Info {
      name: "Add CORS headers to responses",
      kind: Kind::Response
    }
  }

  async fn on_response<'r>(&self, _request: &'r Request<'_>, response: &mut Response<'r>) {
    response.set_header(Header::new("Access-Control-Allow-Origin", "*"));
    response.set_header(Header::new("Access-Control-Allow-Methods", "POST, PUT, DELETE, PATCH, GET, OPTIONS"));
    response.set_header(Header::new("Access-Control-Allow-Headers", "Authorization, Content-Type"));
    response.set_header(Header::new("Access-Control-Allow-Credentials", "true"));
  }
}

/// Разрешает запросы OPTIONS.
#[allow(dead_code)]
#[options("/<_path..>")]
pub async fn cors_options_preflight(_path: std::path::PathBuf) -> MResult<()> { Ok(()) }

И измените async fn rocket():

rocket::build()
  .mount("/", routes![
    cors_options_preflight, // <- позволяет отвечать на OPTIONS-запросы
    // ..
  ])
  .attach(CorsAllower); // <- добавляет разрешающие заголовки

Полезные библиотеки

1. Бэкенд

[dependencies]
base64 = "0.21"
bb8-redis = "0.13"
chrono = { version = "0.4", features = ["serde"] }
data_types = { path = "../data_types" }
dotenv = "0.15.0"
log = "0.4.20"
passwords = "3.1"
rocket = { version = "0.5.0-rc.4", features = ["tls", "json"] }
sea-orm = { version = "0.12", features = ["sqlx-postgres", "sqlx-sqlite", "runtime-tokio-native-tls", "macros", "mock"] }
sea-orm-migration = "0.12"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
sha3 = "0.10"
tokio = { version = "1.33.0", features = ["sync"] }
uuid = { version = "1.5.0", features = ["v4"] }

2. Фронтенд

[dependencies]
async-recursion = "1.0"
chrono = { version = "0.4", features = ["serde"] }
console_log = "1"
data_types = { path = "../data_types" }
dioxus = "0.4"
dioxus-free-icons = { version = "0.7", features = ["bootstrap"] }
dioxus-html = "0.4"
dioxus-web = "0.4"
futures = "0.3"
log = "0.4"
reqwest = { version = "0.11", features = ["json"] }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
web-sys = { version = "0.3", features = ["Storage", "Window"] }

1. Написание функций по отрисовке интерфейса

Для разработки требуется установленная в системе библиотека PyGObject. Её предлагается использовать следующим образом:

import gi

gi.require_version("Gdk", "3.0")
gi.require_version("Gtk", "3.0")

from gi.repository import Gdk, GLib, Gio, Gtk, GObject

Для быстрого прототипирования предлагается отрисовывать формы в Glade и подключать через декоратор:

@Gtk.Template.from_file("main_window.glade")
class MainWindow(Gtk.ApplicationWindow):
  __gtype_name__ = "main_window"
  # подключение к необходимым объектам в прототипе
  rootcont = Gtk.Template.Child("rootcont")

  def __init__(self, **kwargs):
    super().__init__(**kwargs)
    ...

Стилевое оформление прописывается в каскадных таблицах:

provider = Gtk.CssProvider()
provider.load_from_path("./style.css")
screen = Gdk.Screen.get_default()
Gtk.StyleContext.add_provider_for_screen(
  screen, provider, Gtk.STYLE_PROVIDER_PRIORITY_APPLICATION
)

Использование системы сигналов и слотов на примере с кнопками:

self.get_info_btn.connect("clicked", self.show_info_screen)

Документация по PyGObject: https://lazka.github.io/pgi-docs/Gtk-3.0/index.html

2. Добавление логики в приложение

def threaded_logic():
  # some logic
t = Thread(target=threaded_logic)
t.daemon = True
t.start()

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

class MySignals(GObject.GObject):
  __gsignals__ = {
    'get': (GObject.SignalFlags.RUN_FIRST, None, ()),
    'pass': (GObject.SignalFlags.RUN_FIRST, None, ()),
    'default_screen': (GObject.SignalFlags.RUN_FIRST, None, ()),
    'show_error': (GObject.SignalFlags.RUN_FIRST, None, (str,)),
    'show_critical': (GObject.SignalFlags.RUN_FIRST, None, (str,))
  }

signals = MySignals()
some_objects = queue.Queue()

Из потоков напрямую запрещается производить вызов отрисовки интерфейса, равно как и вызывать сигналы (в противном случае - segfault). Предлагается использовать безопасный способ:

Gdk.threads_add_idle(
  GLib.PRIORITY_HIGH_IDLE, signals.emit, 'default_screen'
)
Gdk.threads_add_idle(
  GLib.PRIORITY_HIGH_IDLE, lambda: self.curr_sequencer.prev()
)

3. Последовательность запуска

Сначала запускаются необходимые фоновые потоки, затем - эвентлуп GTK:

class Application(Gtk.Application):
  def __init__(self, *args, **kwargs):
    super().__init__(
      *args,
      application_id="org.comp.app",
      flags=Gio.ApplicationFlags.FLAGS_NONE,
      **kwargs,
    )

  def do_activate(self):
    self.win = MainWindow(application=self)
    self.win.present()
    self.win.show_all()


if __name__ == "__main__":
  Application().run(sys.argv)

Вуаля!

Цифровая трансформация современных предприятий является необходимым ответом на актуальные нормативно-правовые требования и требования современной экономики, ориентированной на использование цифровых решений.

Важной задачей в этих условиях является реализация общенационального курса на импортозамещение иностранного программного обеспечения. Значительная работа в этой области ведется с 2015 года – с момента создания реестра отечественного программного обеспечения. В это же время на государственном уровне предпринимаются меры по организации перехода предприятий с государственным участием на отечественные программные решения, входящие в Реестр российского программного обеспечения [4]. Требования по переходу отечественного бизнеса на российское ПО закреплены также и в национальной программе «Цифровая экономика» [9].

В текущей экономической ситуации российское государство активно поддерживает развитие отрасли информационных технологий, подготовку новых специалистов и особое внимание уделяет обеспечению безопасности данных граждан. В 2022 году было принято решение, что до 2025 года всем предприятиям с зарубежными средствами защиты информации необходимо составить план по переходу на отечественные аналоги [12].

Переход на отечественные программные продукты в первую очередь затронул государственные компании и стратегические производства, особенно в сфере оборонной промышленности. Самым сложным в переходе является замена операционной системы, ведь отечественные разработчики предлагают широкий выбор систем, однако у руководства компаний нет понимания какая операционная система подойдет лучше именно для их производства или бизнеса.

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

Задачи, обеспечивающие достижение поставленной цели, сформулированы авторами следующим образом:

• определение подходов к отбору операционных систем, рекомендованных предприятиям для осуществления процессов импортозамещения в области программного обеспечения;
• выбор и обоснование критериев для сравнения сформированного на предыдущем этапе перечня операционных систем;
• разработка балльных шкал для оценки выбранных операционных систем;
• оценивание выбранных операционных систем по частным критериям и итоговое результирование оценок;
• формализация применения метода оценки и выбора операционной системы, используемой в организации для решения задач цифровой трансформации.

Концептуальные подходы к выбору критериев осуществлены в ходе предварительного исследования [11], обсуждение результатов исследования показало необходимость расширения перечня операционных систем, формализации критериев и шкал балльных оценок для каждого приведенного параметра, а также уточнения показателя, характеризующего экономическую устойчивость организаций-разработчиков.

Объекты и методы исследования

Отбор рассматриваемых продуктов. Выбор ОС для сравнения выполнен на основе данных Реестра российского программного обеспечения (ПО). Были определены следующие требования для отбора операционных систем [11]:

1. Является операционной системой общего назначения (классификатор в Реестре российского программного обеспечения).
2. Использует ядро Linux.
3. Применяется на автоматизированных рабочих местах; имеет сертификат соответствия ФСТЭК.

В результате отбора были выбраны для рассмотрения шесть операционных систем:

1. ОСнова
2. РЕД ОС
3. ALT Linux
4. Astra Linux
5. ICLinux
6. ROSA Linux.

При этом, по состоянию на момент подготовки статьи года сайт ICLinux (https://iclinux.icl.ru) не работал, а на сайте организации – правообладателя (https://icl.ru) не было сведений о данной операционной системе. Поэтому ICLinux в итоге не вошла в список рассматриваемых при выборе решений операционных систем.

Характеристика линейки рассматриваемых ОС. Следует начать с того, что все рассматриваемые операционные системы – разновидности операционной системы GNU/Linux, разрабатываемой международным сообществом на принципах свободного программного обеспечения. Это является преимуществом для разработчиков ПО, так как все эти операционные системы по большей части совместимы между собой и поддерживают различное серверное ПО, средства виртуализации, SMB-протокол, СУБД, офисные и мультимедийные программы, а также большой спектр стороннего ПО и оборудования.

Ниже приведены рассматриваемые продукты:

1) ОСнова – дистрибутив Linux, основанный на Debian и разрабатываемый АО «НППКТ»;

2) РЕД ОС – дистрибутив Linux, основанный на CentOS и разрабатываемый компанией «РЕД СОФТ»;

3) ALT Linux – дистрибутив Linux, изначально основывающийся на MandrakeLinux, ныне являющийся отдельной ветвью развития Linux и разрабатываемый компаниями «Базальт СПО»;

4) Astra Linux – дистрибутив Linux, основанный на Debian и разрабатываемый компанией «НПО РусБИТех», а затем – «РусБИТех-Астра»;

5) ROSA Linux – дистрибутив Linux, основанный на Mandriva и разрабатываемый компанией «НТЦ ИТ РОСА».

Определение критериев выбора. В государственном секторе намечается тенденция к импортозамещению в аппаратной составляющей компьютеров [4, 6, 8]. Поскольку в большинстве своём системы совместимы (РЕД ОС, ALT Linux и ROSA Linux используют пакетную базу RPM, Astra Linux – официальный дериватив Debian, а «ОСнова» также использует пакетную базу Debian), единственным критерием, по которому мы можем оценить систему, – это поддержка архитектур процессоров.

Архитектура x86_64, также известная как AMD64 или Intel 64, является одной из самых распространенных архитектур для персональных компьютеров и серверов. Она разработана компаниями Intel и AMD и представляет собой развитие архитектуры x86. Использует 64-битные инструкции, что позволяет обрабатывать большие объемы данных и обеспечивает поддержку большего объёма памяти (более 4 ГБ). Это позволяет компьютерам выполнять сложные задачи, такие как анализ данных, моделирование и обработка мультимедийного контента.

Архитектура aarch64, известная также как ARM64, разработана компанией ARM и широко используется в современных мобильных устройствах, планшетах, смартфонах и других энергоэффективных устройствах. Она основана на 64-битной инструкционной системе ARM, что позволяет устройствам эффективно использовать энергию и работать дольше от батареи. Архитектура aarch64 стала предпочтительным выбором для мобильных устройств и интернета вещей, где энергоэффективность играет важную роль.

Архитектура «Эльбруса» представляет собой российскую разработку, призванную обеспечить импортозамещение и независимость в сфере информационных технологий. Эти процессоры разрабатываются компанией «МЦСТ». Архитектура «Эльбрус» также поддерживает 64-битные инструкции и предназначена для использования в высокопроизводительных системах и решениях информационной безопасности.

Ниже приведены условные баллы поддержки архитектур процессоров:

• 1 балл – поддержка классической архитектуры x86_64;
• 2 балла – вышеупомянутое, а также поддержка дополнительных архитектур, в том числе мобильной архитектуры aarch64 (armv8);
• 3 балла – вышеупомянутое, а также поддержка отечественных архитектур процессоров, например, «Эльбрус».

Федеральная служба технического и экспортного контроля регулирует применение ПО, в том числе ОС, в защищаемых информационных системах. Помимо этого, вендоры операционных систем могут также разрабатывать свои решения и встраивать их в свою продукцию.

Ниже представлены условные баллы защищённости:

• 1 балл – средняя защита (сертификат соответствия ФСТЭК – минимум ИТ.ОС.А4.П3);
• 2 балла – средняя защита + любые дополнительные программные средства защиты информации, разрабатываемые вендором;
• 3 балла – высокий уровень защиты (сертификат соответствия ФСТЭК – ИТ.ОС.А1.П3).

Для того, чтобы устанавливать операционные системы и обслуживать и администрировать компьютеры с ними, необходимы специалисты. Более того, для бизнеса и в особенности для государственного сектора требуются сертифицированные специалисты. Процедура сертификации системных администраторов условно выглядит следующим образом:

• Обучение работе с целевой администрируемой системой по специальному курсу.
• Прохождение тестирования на знание методологии и особенностей администрирования.
• Получение сертификата.

Ниже приведены условные баллы затрат на подготовку специалистов, которые показывают разницу в 40-60% от стоимости подготовки и сертификации:

• 1 балл – высокая стоимость;
• 2 балла – невысокая стоимость.

По причине необходимости получения заново через определённое время сертификата соответствия ФСТЭК, а также с целью исправления проблем, которые могут быть обнаружены в процессе эксплуатации ОС, необходимо, чтобы компания функционировала как можно стабильнее и могла обеспечивать поддержку и развитие ОС после внедрения на предприятии. Ниже приведены условные баллы, характеризующие уровень экономической устойчивости:

• 0 баллов – кризисное положение;
• 1 балл – низкий уровень устойчивости;
• 2 балла – средний уровень устойчивости;
• 3 балла – высокий уровень устойчивости.

Результаты и их обсуждение

Поддержка аппаратного обеспечения. В таблице 1 приведены поддерживаемые архитектуры процессоров и присвоенные на основании оценки архитектур баллы.

Из таблицы 1 мы можем сделать вывод, что ALT Linux и Astra Linux более подготовлены к этому переходу, что, в свою очередь, напрямую повлияет на доступность локализированной вычислительной техники. Также, если предприятие использует какие-то специфические аппаратные архитектуры процессоров, ALT и Astra имеют возможность покрыть те архитектуры при переходе, которые не смогут покрыть РЕД ОС и ROSA Linux.

Характеристики и оценка программных возможностей защиты информации. Использование защищённых операционных систем в экосистеме компании имеет фундаментальное значение для обеспечения безопасности, стабильности и надёжности работы компании. Защищенные операционные системы предназначены для предотвращения и ограничения атак со стороны злонамеренных акторов, таких как хакеры, вредоносные программы и киберпреступники. Такие системы обладают многоуровневыми механизмами безопасности, которые позволяют выявлять и блокировать угрозы до того, как они станут критическими проблемами для компании или инфраструктуры. Помимо этого, они обеспечивают защиту конфиденциальной информации, обеспечивают изоляцию и ограничение прав доступа для приложений, помогают предотвращать отказы и сбои. Это особенно важно для компаний, которые обрабатывают конфиденциальную информацию или являются объектами критической инфраструктуры. Компрометация операционных систем может привести к серьезным уязвимостям, эксплуатации системы и потере контроля над данными и инфраструктурой, поэтому использование защищенных операционных систем является критическим аспектом.

В таблице 2 приведены решения, созданные и/или применяемые в программных продуктах и связанные с защитой информации, а также информация о сертификатах соответствия ФСТЭК для конкретных редакций дистрибутивов и условные баллы защищённости.

Стоимость подготовки специалистов-администраторов. На данный момент существуют программы сертификации и обучения специалистов для администрирования всех сравниваемых ОС, кроме «ОСнова». Сертификация и обучение для ALT Linux составляет 25 тыс. руб., РЕД ОС – 28-31 тыс. руб., ROSA Linux – 20 тыс. руб., Astra Linux – 36-60 тыс. руб.[5, 7]

Уровень экономической устойчивости. Оценка экономического положения организаций – разработчиков сравниваемых операционных систем позволяет сделать прогноз относительно уровня стабильности поддержки рассматриваемых в работе операционных систем в дальнейшем.

Необходимо отметить, что задача оценки экономической устойчивости организаций - разработчиков операционных систем и в целом, организаций, работающих в области разработки компьютерного программного обеспечения и консалтинга в данной области, пока является нерешенной. Один из вариантов решения, примененный авторами, предполагает подход, обратный оценке экономической устойчивости, и применение моделей, характеризующих уровень финансовой состоятельности при оценке вероятности банкротства организаций. Использование такого подхода требует вдумчивого выбора наиболее подходящих для решения подобной задачи моделей оценки финансовой состоятельности.

Для выбора моделей и принимая во внимание особенности экономического содержания моделей, опирающихся на показатели бухгалтерской отчетности, характеризующие финансовое положение организаций, следует обратиться к используемым в разных моделях страновым, отраслевым и временным выборкам. И здесь мы увидим ряд моделей, обладающих широкой известностью и высокой популярностью, которые построены на данных американских рынков в пределах относительно узких временных периодов. Это связано, отчасти и с тем, что интерес к решению задач прогнозирования вероятности банкротства становится высоким в тех случаях, когда сама вероятность банкротства организаций тоже повышается, то есть в периоды экономических кризисов и в первые посткризисные годы. Вторая особенность обсуждаемых моделей, заключается в довольно широких отраслевых выборках. Так, классическая пятифакторная дискриминантная модель Альтмана построена на данных публичных акционерных компаний. Более адекватными для решаемой в работе цели оценки являются дискриминантные модели, построенные на данных, характеризующих деятельность непроизводственных компаний американского рынка, и на данных, характеризующих деятельность компаний на развивающихся рынков. В последней модели используется повышающий коэффициент, отражающий более высокую нестабильность развивающихся рынков в целом.

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

Таким образом, в основу оценки экономической устойчивости организаций была положена комплексная оценка финансовой состоятельности, выполненная по трем моделям: дискриминантным моделям Альтмана для непроизводственных компаний (Z-score) и для развивающихся рынков (EM Z-score), а также по логит-модели О. Е. Большаковой [2].

Выбранные для оценки модели демонстрируют низкую вероятность ошибки прогноза отсутствия банкротства компании - 0,006 [1], то есть позволяют с высокой степенью точности определить стабильность состояния компании. Оценка финансовой устойчивости компаний выполнена в динамике за 2019-2022 гг. Данные для оценки взяты из открытых источников.

При интерпретации результатов в дискриминантных моделях используется стандартное значение индекса – 2,6.

При интерпретации результатов оценки логит-модели введен ограничивающий оценку критерий – 0,25. Полученные значения логит-модели ниже 0,25 трактуются как характеристика финансово устойчивого положения компании.

В таблицах 4-6 представлены результаты расчетов индексов и оценок по выбранным для комплексной оценки финансовой состоятельности организаций - разработчиков программного обеспечения моделей.

Отметим, что ООО «НТЦ ИТ РОСА»перешло в 2022 г. на упрощенную систему налогообложения, что ограничило возможности оценки по данным открытых источников. Это специфическое положение организации отмечено в таблицах 4-6*. О компаниях АО «НППКТ» и ООО «РусБИТех-Астра» в открытых источниках, публикующих сведения о финансовой отчетности организаций по данным Федеральной налоговой службы, сведения на момент проведения исследования отсутствуют, что может быть связано с особыми условиями функционирования этих организаций и использования разрабатываемых ими решений, поэтому при оценке мы опирались на данные отчетности за предшествующие годы. Эти особенности отмечены в таблицах 4-6**.

В таблице 5 представлен результат расчета индекса дискримиантной модели, разработанной для оценки финансовой состоятельности организаций, работающих на развивающихся рынках. Особенностью данной модели является отражение более высокую нестабильность, характерную для развивающихся рынков.

Анализ представленных в таблице результатов позволяет сделать вывод о высоком уровне финансовой устойчивости представленных в обзоре организаций. Положение только одной организации - ООО «НТЦ ИТ РОСА» является неустойчивым на протяжении всего периода, при этом динамика индекса свидетельствует об улучшении финансового состояния организации.

В таблице 6 представлены оценки логит-модели для анализируемых в работе компаний - разработчиков программного обеспечения. Итоговая оценка принимается на основе рассчитанного за представленный временной диапазон среднего значения оценки и сопоставления его с критическим значением, выбранным для данной модели.

Особенностью данной логит-модели [2], является использование динамических показателей. Так, для оценки используется показатель средней кредиторской задолженности. Такая логика расчета потребовала от авторов расширения диапазона данных, в расчетах, в частности, использовались данные за 2018 г.

Отметим, что для большинства анализируемых организаций положение стабильно в течение всего рассматриваемого периода. ООО «Ред Софт» и ООО «Базальт СПО» демонстрируют финансовую устойчивость при оценке их положения каждой из моделей. Положение ООО «НТЦ ИТ РОСА» является критическим на протяжении всего рассматриваемого периода, но при этом по результатам оценки с использованием дискриминантных моделей организация демонстрирует положительную динамику индексов, значение EM Z-score по результатам 2021 г. приближается к пороговому значению, а при оценке с помощью логит-модели мы видим ухудшение финансового положения организации и повышение риска банкротства.

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

Условные баллы определены как сумма интерпретируемых значений трех моделей, при этом в каждом случае при достижении необходимого значения показателя присваивается оценка «1», в противном случае – «0».

Распределение условных баллов. В таблице 8 приведено распределение условных баллов по операционным системам. В таблицу включены выше разработанные критерии оценки и выполненные в ходе работы оценки по балльным шкалам. По каждому частному критерию оценки, расчеты по которым представлены в таблицах 1-7, представлены баллы. В строке «Итого» суммируются баллы по частным критериям для каждой операционной системы. Наиболее предпочтительными для выбора являются операционные системы, по которым получены максимальные итоговые значения баллов.

Заключение

В результате сравнения операционных систем наиболее предпочтительным представляется выбор среди двух вариантов: ALT Linux и Astra Linux. При этом выбор может быть скорректирован с учётом поставленных перед организацией задач: так, например, с точки зрения средств программной защиты информации безусловным лидером выходит Astra Linux, которая имеет сертификацию ФСТЭК для обработки совершенно секретной информации (ИТ.ОС.А1.П3), что выступает важным критерием для применения ОС на предприятиях – объектах КИИ и в государственных органах. В то же время стоимость подготовки специалистов администрирования для ALT Linux существенно ниже, а класс защиты вполне приемлемый для бизнеса.

При этом, несмотря на наличие дополнительных встраиваемых программных средств защиты информации в «ОСнова» и ROSA Linux, надо принимать во внимание, что для первой ОС нет программ сертификации специалистов, а экономическое положение организации-разработчика второй характеризуется как кризисное.

Разработанный алгоритм и критерии выбора операционных систем помогает принять решение о выборе операционной системы, внедрение и эксплуатация которой наиболее полно отвечает потребностям и перспективам развития организации, с учётом того, что все представленные в анализе решения отвечают минимальным требованиям регуляторов.

Литература

1. Березинец И. В., Бобылева А. З., Ильина Ю. Б. Вероятность банкротства: достоверны ли модели прогнозирования? // Государственное управление. Электронный вестник. 2022. №94.
2. Большакова О. Е., Максимов А. Г., Максимова Н. В. О моделях диагностики состоятельности предприятий малого и среднего бизнеса // Вестник ВГУ. Серия: Экономика и управление. 2014. №3.
3. ИТ-курсы по вендорам. [Электронный ресурс]. Режим доступа: https://edu.softline.com/vendors/ (дата обращения: 10.05.2023).
4. Корпорация «Тактическое ракетное вооружение»: импортозамещение программного обеспечения идет успешно [Электронный ресурс]. Режим доступа: https://2009-2020.oborona.ru/includes/periodics/defense/2020/0117/173128505/detail.shtml (дата обращения: 16.05.2023).
5. Перечень курсов Академии информационных систем. [Электронный ресурс]. Режим доступа: https://www.infosystems.ru/about/price/ (дата обращения: 15.05.2023).
6. Полное импортозамещение: производство отечественных процессоров Эльбрус хотят перенести из Тайваня в Россию. [Электронный ресурс]. Режим доступа: https://www.ferra.ru/news/techlife/polnoe-importozameshenie-proizvodstvo-otechestvennykh-processorov-elbrus-khotyat-perenesti-iz-taivanya-v-rossiyu-30-05-2022.htm (дата обращения: 15.05.2023).
7. Работа в России, поиск персонала и публикация вакансий. [Электронный ресурс]. Режим доступа: https://hh.ru/search/vacancy?area=113&professional_role=113&professional_role=116&professional_role=114&professional_role=121&search_field=name&search_field=company_name&search_field=description&enable_snippets=false&text=Astra+Linux&ored_clusters=true (дата обращения: 10.05.2023).
8. Разработчик «Эльбруса» оценил поправки в документ об импортозамещении. [Электронный ресурс]. Режим доступа: https://www.ferra.ru/news/techlife/polnoe-importozameshenie-proizvodstvo-otechestvennykh-processorov-elbrus-khotyat-perenesti-iz-taivanya-v-rossiyu-30-05-2022.htm (дата обращения: 15.05.2023).
9. Распоряжение Правительства РФ от 28.07.2017 N 1632-р «Об утверждении программы «Цифровая экономика Российской Федерации».
10. Реестр российского программного обеспечения. [Электронный ресурс]. Режим доступа: https://reestr.digital.gov.ru/ (дата обращения: 04.07.2023).
11. Титов К. А., Водяницкая С. И. Концептуальные подходы к сравнению российских операционных систем с открытым кодом // Научные исследования 2023: актуальные теории и концепции : сборник материалов XXIX-ой международной очно-заочной научно-практической конференции, Москва, 24 мая 2023 года. Том 1. – Москва: Научно-издательский центр «Империя», 2023. – С. 39-43. – EDN FJMJAT
12. Указ Президента Российской Федерации от 01.05.2022 г. № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации».
13. Указ Президента РФ «Вопросы Федеральной службы по техническому и экспортному контролю» от 16.08.2004 №1085.

На данном этапе требуется создать два раздела на имеющихся у вас накопителях: один - для EFI, другой - для системы. Диск следует разметить как GPT.

Вики: https://wiki.archlinux.org/title/fdisk

Этап второй. Создание разделов

# mkfs.vfat -F32 /dev/{EFI-раздел}

# cryptsetup --key-size 512 --hash sha512 luksFormat /dev/{системный раздел}

# cryptsetup open /dev/{системный раздел} root

# mkfs.btrfs /dev/{системный раздел}

# mount -o compress-force=zstd:4 /dev/{системный раздел} /mnt

# mount --mkdir /dev/{раздел EFI} /mnt/boot/efi

Этап третий. Установка пакетов и настройка системы

# pacman -Sy reflector

# reflector --save /etc/pacman.d/mirrorlist --latest 5 --country Russia --protocol https

# pacstrap -K /mnt base base-devel {ядро, например, linux} linux-firmware efibootmgr {менеджер сети, например, networkmanager} {текстовый редактор, например, nano}

# genfstab -U /mnt > /mnt/etc/fstab

# arch-chroot /mnt

# nano /etc/locale.gen

Выбираем нужные нам локали и запускаем далее:

# locale-gen

# echo LANG={локаль, например, en_US.UTF-8} > /etc/locale.conf

# ln -sf /usr/share/zoneinfo/{регион}/{город} /etc/localtime

# hwclock --systohc --utc

# echo {имя хоста} > /etc/hostname

# nano /etc/hosts

Пишем:
127.0.0.1 localhost {имя хоста}
:: 1 localhost {имя хоста}

# systemctl enable NetworkManager

# dd bs=512 count=4 if=/dev/urandom of=/crypto_keyfile.bin

# cryptsetup luksAddKey /dev/{системный раздел} /crypto_keyfile.bin

# chmod 600 /crypto_keyfile.bin

Нам потребуется вручную собрать загрузчик, поэтому выбираем yay из любого репозитория: https://pkgs.org/search/?q=yay

# curl {ссылка на yay из одного из репозиториев, например, https://arch.alerque.com/x86_64/yay-12.0.4-1-x86_64.pkg.tar.zst}

# pacman -U {имя файла пакета, например, yay-12.0.4-1-x86_64.pkg.tar.zst}

# passwd

# useradd -m {имя пользователя}

# passwd {имя пользователя}

# EDITOR=nano visudo

Вписываем после строки
root ALL=(ALL:ALL) ALL
строку:
{имя пользователя} ALL=(ALL:ALL) ALL

# sudo -iu {имя пользователя}

$ yay -S grub-improved-luks2-git

$ sudo nano /etc/mkinitcpio.conf

Редактируем следующие строки:
MODULES=(btrfs vfat)
FILES=(/crypto_keyfile.bin)
HOOKS=(base udev autodetect modconf kms keyboard keymap block encrypt filesystems fsck)

$ sudo mkinitcpio -P

$ sudo chmod 600 /boot/initramfs-linux*

$ sudo nano /etc/default/grub

Редактируем следующие строки:
GRUB_CMDLINE_LINUX="cryptdevice=UUID={UUID системного раздела, смотрим через команду "lsblk -f"}:root root=/dev/mapper/root"
GRUB_ENABLE_CRYPTODISK=y

$ sudo grub-mkconfig -o /boot/grub/grub.cfg

$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB

$ sudo nano /boot/grub/grub-pre.cfg

Пишем:
set crypto_uuid={UUID системного раздела}
cryptomount -u $crypto_uuid
set root=crypto0
set prefix=($root)/boot/grub
insmod normal
normal

$ grub-mkimage -p /boot/grub -O x86_64-efi -c /boot/grub/grub-pre.cfg -o /tmp/grubx64.efi luks2 part_gpt cryptodisk gcry_rijndael gcry_sha512 argon2 btrfs

$ sudo install -v /tmp/grubx64.efi /boot/efi/EFI/GRUB/grubx64.efi

После этого, дважды нажав Ctrl+D, выходим в консоль archiso и вводим:

# umount -R /mnt

# reboot

0. Обучение

0.1. IT-ресурсы

https://t.me/it_tochka - точка входа в IT

https://t.me/habr_com - без комментариев канал лучшего айтишного сайта Рунета

https://t.me/it_chats - чаты в Телеграме по разным технологиям, языкам программирования, вакансиям и прочему

https://t.me/sec_devops - канал, в котором публикуются материалы о выстраивании безопасного DevOps

https://t.me/structuredata - всё про алгоритмы и структуры данных

https://t.me/seniorFront - всё для фронтенда

https://t.me/it_guides - гайды программиста

https://t.me/physics_lib - книжки для технарей

https://t.me/eda_shad - чатик от ЕДА

https://t.me/devo_pes - DevOps для девопсов

https://t.me/cm_books - литература для разработчиков, ещё есть https://t.me/+fVscRbjiGfVkODgy

https://t.me/proglibrary - библиотека программиста

https://t.me/gebutcher/8232 - ИБ-телега

0.2. Ресурсы для бизнеса, финансов, маркетинга и связанного

https://t.me/markettwits - оперативные краткие новости из финансового сектора

https://t.me/forbesrussia - канал русского Forbes

https://t.me/business_ru - бизнес в одном месте

https://t.me/joinchat/AAAAAFgITvCoA4h2nuug8A - "Анонсируем различные курсы, лекции, марафоны, сообщаем о различных форумах и образовательных программах"

https://t.me/creativestar - современный маркетинг, ещё есть https://t.me/sell_me и https://t.me/marketingold

https://t.me/digital_review - тренды

https://t.me/remingtonist - карты, тексты, два ствола

https://t.me/ludobreniya - бренды и пиар

https://t.me/finside - банки, инвестиции, финтех, ещё есть https://t.me/Coin_Post

https://t.me/investfuture - медиа про деньги

https://t.me/illyuziya_obmana_risk_menedjment - риск-менеджмент

https://t.me/economika - экономика

https://t.me/vcnews - "Бизнес, технологии, идеи, модели роста."

https://t.me/epicgrowth - рост продуктов, ещё есть https://t.me/product_and_project

https://t.me/bizcult - бизнес-культура

0.3. Ресурсы для дизайнеров

http://t.me/+2BgCKREek4Y4YzI6 - шрифты для коммерческого и личного использования

https://t.me/Figmachex - Фигмач

https://t.me/onbehancer - лучшее с Behance, ещё есть https://t.me/+ImpMwqnYaQY0OTYy

https://t.me/figma2html - макеты для вёрстки, ещё есть https://t.me/true_figma

https://t.me/TheDesignus - Дизайнус

0.4. Саморазвитие

https://t.me/Chitat_onlain_Biblioteka - книги по саморазвитию

https://t.me/bezaspera - "Меня зовут Арина Хромова, я карьерный эксперт и сооснователь @careerspace. Пишу о карьере, управлении командами и стартапах."

1. Резюме

https://rxresu.me/ - создаёт резюме из текста

https://t.me/resume_review - группа, где могут проверить ваше резюме

2. Вакансии и стажировки

https://t.me/changellenge - главный ресурс топовых вакансий в российских компаниях. https://changellenge.com/ - сайт Changellenge

https://t.me/appsec_job - работы в сфере информационной безопасности (AppSec + DevSecOps). Ещё есть https://t.me/RuSecJobs

https://t.me/webfrl - веб-фриланс

https://t.me/mtsfintechjobs - Финтех МТС

https://t.me/vcjob - вакансии от vc.ru

https://t.me/cppdevjob и https://t.me/pydevjob

https://t.me/naukauniver - новости науки и ВО, вакансии

https://t.me/studyqa - стажировки за рубежом, ещё есть https://t.me/joinchat/kQLQUGltbEtjYzQ6

https://t.me/+Bi7qpPB6byhlODRk - "Стажировки, гранты, стипендии, волонтерства и вакансии для молодых специалистов. В России и за рубежом."

https://t.me/+FnVpKeIdv55iYzQy - маркетплейс для фриланса

https://t.me/workcamp - работа в IT

https://t.me/habr_career - вакансии от Хабра

https://fut.ru/catalog/ - стажировки и лидерские программы

https://jobby.ai/student_jobsearch - стажировки для студентов от Jobby

На закуску

Все хакатоны России

Leader ID

Университет 2035

Профессионалы 4.0

Чтобы написать рабочее расширение для Джеффа, нужно:

1. Написать код для общения расширения и Джеффа (потому что они общаются путём передачи JSON поверх обычных TCP-сокетов). Если вы пишете на Python, для вас уже всё сделали, для других ЯП пока ещё ничего нет.
2. Написать конфигурационный файл extension.j.json. В минимальной комплектации он выглядит так:
   {
"name": "some_name",
"title": "Some title",
"desc": "Some desc",
"license": "Some Open-Source or some proprietary",
"program": "/path/to/program"
}
   В папках с расширениями полно примеров.
3. Написать нужную вам логику.

Общение, как было упомянуто выше, происходит за счёт обмена информацией по TCP-протоколу. Расширение добавляется через диалоговое окно Джеффа и впоследствии стартует и завершается вместе с ним. Большинство расширений использует механизм аргументов для передачи портов сокетов:
"args": [
"alias-maker.py",
"<SERVER_PORT>",
"<JEFF_PORT>"
],
"server_ip": "",
"server_port": 23179
В итоге вместо <SERVER_PORT> подставится 23179, указанный ниже, а вместо <JEFF_PORT> подставится порт Джеффа, который можно изменять в настройках.

Не все расширения обязаны иметь сервер; напротив, некоторые могут только что-то отправлять в Джеффа и ничего от него не ждать. Например, так работает vosk-voice-input-daemon.

Какие возможности предоставляет Джефф для расширений?

1. Внутренняя память.
   В Джеффе есть общее между всеми расширениями хранилище JSON-объектов.
   Вот так выглядит запрос на получение данных: {"memory_cells": ["needed_memory_cell_1", "needed_2", "needed_3_etc"]}
   - и на сохранение: {"store_in_memory": {"some_key": "some value, even decimal, double, boolean, object or array"}}.
   Причём по умолчанию каждый запуск три ячейки - jeff-lang, jeff-os, jeff-bundle-dir заполняются Джеффом.
2. Получение сообщений.
   Если вы указали в файле конфигурации расширения, что у него есть сервер, это значит, что Джефф будет вам отправлять сообщения пользователя каждый раз, когда сам не сможет на них ответить. Если вы хотите всегда передавать ввод пользователя в расширение, добавьте в конфигурацию строчку "always_send": true.
3. Отправка сообщений.
   Вот примеры JSON запросов на отправку:
   {"send": "какое-то сообщение на отправку"}
{"send_as_user": "сообщение на отправку от лица пользователя"}
{"send_info": "информация от расширения"}
{"send_warning": "предупреждение"}
{"send_status": {"id": "уникальный идентификатор обновляемого сообщения", "msg": "сообщение, которое может меняться со временем"}}
4. Добавление выражений в базу данных.
   Делается это так:
   {"add_expr": [
{
"activator_text": "пользовательский ввод",
"reagent_text": "ответ Джеффа",
"properties": {"какие-то свойства": "их значения",..},
"exec": false | true
},..
]}
5. Эксклюзивное общение по сценарию.
   В сущности, сценарий представляет из себя способ взаимодействия, когда весь ввод пользователя без обработки перенаправляется в одно расширение. Джефф в этом смысле работает как паром.

Если у вас есть идеи расширений, или вы уже написали расширение и хотите им поделиться, пишите!

У меня пусто в душе. Я не так часто вижу свет в конце тоннеля, как хотелось бы. Внешне я энергичен и искусен, но сладкие яства жития не укрепляют мои ноги. Возможно, тебе предстоит ответить на самый главный вопрос в твоей жизни - зачем тебе всё это?

Когда я соотносил собственное существование со Вселенной и её обитателями, я думал об утилитаризме, гедонизме. В определённый момент я изобрёл для себя сказку о консеквенциализме с критерием расширения свободы действий, в рамках которой показал математически и логически разрешение гильотины Юма, исходя из научной теории о происхождении человека: человек должен иметь свободу, но необязательно ей пользоваться.

И что мне это дало? Я создавал свободу, вполне свободно ей пользовался. И во благо себе, и во вред, - всяко умеренно. Но изнутри меня глодало чувство, что я пытаюсь себе доказать что-то. Я пишу книги и рассказы, программы и песни, дневники и планы, строю своё будущее и искренне верю в хорошее. Я верю в людей и капитализм, правда, не в тот, что существует в искажённом понимании политиков. Разве ограничение свободы других по причине явления личности некоей абсолютной истины истинно само по себе?

Я боюсь, что, даже определяя то, что для меня правильно и что нет, ошибаюсь. Меня каждый раз вытаскивают из этого разные люди, которым я очень благодарен. Я боюсь одиночества, понимая, что из-за своих знаний и внешней необходимости внутренне никому точно не буду нужен.

Дитя, не знаю, какую сказку тебе рассказать, чтобы было чему научиться в ней. Не знаю, что есть жизнь и как человек провернул гигантский скачок в эволюции, естественной и социальной. Не знаю, докажем ли мы гипотезу Римана и найдём ли супериорный алгоритм шифрования. Не знаю даже, обоснована ли наука и вера в неё, или же она неотличима от религии. Не знаю, по какому праву глубоко религиозные люди считают атеистов аморальными, и не знаю, как жить атеисту, когда у религиозных есть совершенная вера.

Но каждое утро рано встаю, хоть и боюсь, что этот автоматизм уже не скрывается. Занимаюсь физически и умственно, хоть и боюсь, что не тем. Трачу себя, хоть и боюсь, что не на то и не на тех.

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

Но всё-таки что-то я узнал вчера ночью. Это твой урок, милое дитя.

Вселенная тоже пуста. Но быть живой ей это не мешает.

Если вкратце — технологии постоянно меняются. Если раньше мы использовали для защиты узкие утилиты, выполняющие одну-две задачи, совсем недавно — комплексные антивирусы и программы для защиты инфраструктуры, то сейчас для полноценной защиты используются ячеистые архитектуры кибербезопасности вкупе с сервисами по защите от сетевых рисков, под капотом у которых — нейронные сети. И это только часть того, чем живёт современная информационная безопасность. Ваш покорный слуга проанализировал отчёты SOC Prime, SANS Cloud Security, Mandiant и Gartner за последние два года, чтобы составить портрет современной архитектуры информационной безопасности на предприятии и в программных продуктах, а также её скорого будущего.

Для того, чтобы иметь возможность пользоваться различными аналогами средств ОИБ и позволять им консолидировать источники информации для принятия оперативных решений, люди придумали ячеистые архитектуры кибербезопасности — CSMA. CSMA имеет четыре основных уровня:

1. Аналитика безопасности и интеллект.
2. Сводные информационные панели.
3. Распределённая идентификационная ткань.
4. Консолидированные политика и управление доступом.

Чтобы поддерживать CSMA, разработчики средств ОИБ повсеместно внедряют в свои продукты открытые стандарты и общие API для поддержки интеграции сторонних поставщиков.

Сервисы по защите от сетевых рисков и их составные элементы — решения по управлению внешней поверхностью атаки и атаки киберактивов — предназначены для анализа внешних и внутренних компонентов локальной сети вашей организации и их мониторинга в режиме реального времени. Многие системы DRPS обогащены возможностями Threat Intelligence, но в основном предназначены для проактивных действий по выявлению и блокировке внешних угроз. Но CAASM предназначены для анализа локальной сети и всех устройств в нём, в то время как EASM-системы зачастую являются системами защиты бренда — Brand Protection — и анализируют мошеннические сайты при помощи разведки по открытым источникам (OSINT) с целью обнаружения относящихся к организации данных. Современные CAASM- и EASM-системы используют машинное обучение для выявления угроз. Наиболее популярными DRPS-продуктами во всём мире являются BlueVoyant Sky: DRP, CybelAngel ERPP, Digital Shadows SearchLight; в России — BI.ZONE Brand Protection, Group-IB Digital Risk Protection, Infosecurity ETHIC и Kaspersky Threat Intelligence.

Технологии управления идентификацией и доступом предназначены для защиты данных путём реализации политик доступа к сведениям. Благодаря идентификации пользователей мы можем понимать, какие сведения им можно передавать и раскрывать, а какие — нельзя. Помимо применения к пользователям IAM используются для идентификации промежуточных сервисов. К самым известным продуктам относятся такие программные продукты, как SELinux (подсистема Linux, начиная с версии 2.6), Secret Net, Sber Platform V; помимо них, существуют ещё и аппаратные средства, такие, как «Соболь» Кода Безопасности. К облачным продуктам и интерфейсам для конечных пользователей относят такие составляющие IAM, как многофакторную аутентификацию, аутентификацию на основе сертификатов и сторонние сервисы аутентификации (например, Google или Microsoft OAuth). А поскольку такие системы часто подвергаются атакам как чуть ли не единственные барьеры на пути к данным и управлению КИИ, для выявления атак на IAM и оперативного реагирования на инциденты существуют инструменты для распознавания и реагирования на угрозы идентификации — ITDR. Многие продукты IAM по умолчанию включают в себя инструментарий ITDR.

Системы аудита, отслеживания и защиты данных необходимы, в свою очередь, для разграничения данных, равно как и IAM; фундаментальное различие между ними заключается в контентном разграничении доступа, а не в файловом. Также DCAP-системы позволяют анализировать данные и организовывать хранение информации и доступ к ней максимально эффективно и безопасно. Аналитики прогнозируют в будущем поглощение DCAP-системами DLP и повсеместное использование из-за ужесточения контроля за персональными данными со стороны регулятора. DLP же, как системы контроля каналов передачи данных, ищут и категоризируют критичную информацию, предотвращая её перемещение и передачу за пределы периметра корпоративного контура безопасности. К системам DLP относят DAM, системы мониторинга активности баз данных.

Системы выявления событий ИБ в реальном времени позволяют распознать потенциальные угрозы безопасности и уязвимости до того, как они станут способны нанести удар бизнесу. Такие системы покрывают аномалии в поведении пользователя, используя для этого машинное обучение. Самые популярные системы SIEM в России — это Ankey SIEM, Kaspersky Unified Monitoring and Analysis Platform и KOMRAD Enterprise SIEM.

Системы кибербезопасности для облачных приложений объединяют SIEM, DCAP/DLP и IAM для обеспечения кибербезопасности по отношению к важным данным, располагаемым не в корпоративной сети организации, а в сети облачного провайдера. Такие системы, как правило, унитарны и совмещают в себя множество продуктов. Самый известный пример — Microsoft Cloud Security Solutions. Зачастую такие системы сочетаются с защитой от DDoS-атак, позволяя фильтровать подозрительные запросы к серверам.

Существуют также и комплексные решения для организации безопасности, автоматизации и реагирования, предназначаемые для сбора информации о событиях информационной безопасности и автоматизации типовых сценариев реагирования на них, избавляя специалистов ИБ от необходимости управлять каждым из защитных решений в отдельности и помогая им сфокусироваться на анализе сложных инцидентов. Ключевое отличие SOAR от SIEM в этом ключе заключается в том, что SOAR рассчитаны именно на на автоматизацию. Самые популярные системы иностранных разработчиков — IBM Resilient SOAR, Cortex XSOAR и Cisco SecureX, российских — R-Vision IRP.

Для анализа сложных инцидентов зачастую своих специалистов бывает недостаточно, поэтому очень часто компании обращаются к сервисам EaaS, предоставляющим стороннюю профессиональную экспертизу инцидентов ИБ.

Для превентивного исправления уязвимостей существует целая отрасль кибербезопасности, называемая Threat Intelligence — TI. Дистрибутив Linux «Ubuntu» позволяет исправлять уязвимости в ядре без перезагрузки системы (Ubuntu Livepatch Service), а CTSE позволяет организовывать поиск по имеющимся уязвимостям (обычно им присваиваются номера в координатах CVE).

При этом для реальной защиты БТКС сами сервисы и технологии, использующие телекоммуникационные технологии, должны предполагать наличие защитных механизмов, которые следует закладывать на этапе их проектирования.

Например, для разработки облачного программного продукта команда программистов должна обладать минимальными навыками обеспечения защиты информации, используя:

1. Хэширование вместо прямой передачи данных аутентификации
2. Хранение токенов и иной критической информации в защищённых местах, таких, как аппаратные доверенные хранилища или удалённые облачные сервисы.
3. Защиту от случайных или намеренно испорченных вводимых данных путём проверки всей внешней информации.
4. Безопасное управление внутренней памятью программы.
5. Постоянное сканирование на уязвимости исходного кода при помощи специальных инструментов и статических анализаторов.
6. Систему внедрения исправлений.
7. Систему поиска уязвимостей в базах данных и реагирования на инциденты.
8. Современные стандарты шифрования данных.

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

При этом развивается сфера квантовых вычислений, позволяющих добиться расшифровки передаваемых по HTTPS-соединениям сообщений путём использования квантовых компьютеров. Например, китайские исследователи сообщили об успешном взломе RSA: это будет означать возможность расшифровки сообщений за фиксированное небольшое время для стандартных алгоритмов шифрования, основанных на простых числах.

В то же время исследователи уже предлагают специализированные стандарты шифрования, которые будут устойчивы к расшифровке сообщений квантовыми компьютерами. В них используются ключи до 3072 бит длиной и совершенно другие алгоритмы, для которых не существует на данный момент контралгоритмов для квантовых компьютеров. Но этот момент — очень условный, и поэтому сфера информационной безопасности — самая динамично развивающаяся сфера на стыке IT и точных наук, требующая от специалистов этой сферы постоянного развития своих компетенций.

Помимо защиты от раскрытия информации, зачастую необходимо обеспечивать неизменяемость определённой информации, такой, как истории банковских транзакций и т. п. Для этих целей разрабатываются системы, применяющие в своей работе технологию блокчейна, и децентрализованные сервисы, которые в ближайшем будущем станут стандартом нового Интернета — Web3.

Таким образом, правильно сочетая общепринятые стандарты в области ОИБ, требования регуляторов и современные технологии ОИБ, можно добиться беспрецедентного уровня информационной безопасности, основанной на физических принципах и интеллектуальном подходе.

Литература:

1. Бондарев В. В. Введение в информационную безопасность автоматизированных систем [Текст] / В.В. Бондарев // М.: МГТУ им. Н. Э. Баумана — 2014.
2. Бёрд Д. DevOpsSec [Текст] / Джим Бёрд // O’Reilly — 2016.
3. Информационная безопасность телекоммуникационных систем: https://searchinform.ru/informatsionnaya-bezopasnost-telekommunikatsionnykh-sistem/
4. Информационная безопасность: руководство по защите от внутренних угроз. Комплексная защита данных – СёрчИнформ, 2022 (www.searchinform.ru).
5. Основные сценарии реализации угроз на АСУ ТП и их преломление на методику оценки угроз ФСТЭК – Алексей Лукацкий, Cisco Secure, 2021.
6. ПАК «Соболь». Код Безопасности: https://securitycode.ru/products/pak_sobol/
7. Семь трендов информационной безопасности 2022: https://www.cnews.ru/reviews/security2022/articles/sem_trendov_informatsionnoj_bezopasnosti
8. Технология блокчейн: что надо знать в 11 карточках: https://trends.rbc.ru/trends/industry/5f05c0a79a7947aac5c7577a
9. Физики реализовали масштабируемую сеть квантовой коммуникации: https://nplus1.ru/news/2020/09/03/8-user-quantum-communication-network
10. At a glance: PCI DSS v4.0 – PCI Security Standards Council LLC, 2022.
11. CSMA is more than XDR: An introducion to cybersecurity mesh architecture: https://coffee-web.ru/blog/csma-is-more-than-xdr-an-introducion-to-cybersecurity-mesh-architecture/
12. Detection as Code Innovation Report 2021: The Power of Collaborative Cyber Defence – SOC Prime, 2021 (www.socprime.com).
13. Hype Cycle for Security Operations – Gartner, 2022.
14. MITRE ATT&CK: https://attack.mitre.org/
15. Market Guide for Security Orchestration, Automation and Response Solutions – Gartner, 2022.
16. Nine Key Cloud Security Concentrations & Securing Web Application Technologies Checklist – SANS Cloud Security, 2022 (www.sans.org/cloud-security).
17. Special Report: M-TRENDS 2022 – Mandiant, 2022 (www.mandiant.com).
18. What ITD and ITDR means in a Zero-Trust world? https://venturebeat.com/security/what-identity-threat-detection-and-response-itdr-means-in-a-zero-trust-world/
19. What is SIEM? https://ibm.com/topics/siem

На текущий момент основная угроза информационной безопасности любого персонального компьютера исходит от двух факторов: использования непроверенного программного обеспечения и человеческих ошибок, связанных с этим. Между тем, защита ПК также критически важна, как и защита корпоративных и государственных систем. Человеческий фактор играет здесь не последнюю роль: часто происходит так, что в организациях со слабо развитой культурой информационной безопасности сотрудники берут с работы важные документы, чтобы продолжить работу над ними в домашних условиях, то есть на не аттестованных для сведений, составляющих коммерческую или государственную тайну, компьютерах. Это не говоря уже о том, что личные финансовые, конфиденциальные данные, в том числе пароли, точно так же остаются беззащитны перед похищением, уничтожением или шифровальщиками. Программные же угрозы постоянно мимикрируют под ПО, знакомое для пользователя, в связи с чем практически невозможно его отличить даже опытным пользователям и специалистам, а антивирусные базы, создаваемые по сигнатурам уже известных угроз, бессильны перед неизвестными. В том числе не исключен вид угроз, когда в очередном обновлении проверенного ПО привносится код, который в итоге выполняет несанкционированные действия.

Как мы можем в таком изменчивом мире обеспечить безопасность рядовому пользователю? Если за компьютер посадить специалиста по информационной безопасности, он будет способен эксплуатировать его с соблюдением требований ИБ, но к обычному человеку не предъявляются требования, какие обычно предъявляют к подобного рода специалистам.

Характеристики средства обеспечения ИБ

Чтобы решить проблему, нужно создать программный комплекс, который будет способен отслеживать все виды угроз, способных причинить вред информации и/или их владельцу. Такой комплекс должен обладать следующими свойствами:

• гибкость - способность реагировать на широкий круг угроз
• скорость - способность за короткое время определять угрозы
• точность - способность гарантировать безопасность.

Такую задачу решить под силу только машинному обучению в виде нейросетей.

Почему нейронным сетям можно доверять столь сложную и важную задачу?

Машинное обучение доказало свою состоятельность на ряде задач. Например, автопилоты Tesla и Яндекса позволяют ездить на автомобилях без водителей; нейросеть Google NMT сделала их сервис перевода соотносимым по качеству с человеческим переводом; машинное зрение позволяет определять по кадрам Google Street View названия улиц, магазинов и других мест; в медицине Adversarial Auto Encoder помог найти 69 молекул, половина из которых используется в борьбе с раком; FGSM позволяет противостоять распознаванию лиц в Интернете путем добавления невидимых для человеческого глаза пикселей.

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

Почему классические антивирусы не будут так эффективны?

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

Активный же анализ основывается на нескольких важных компонентах, например, системе разграничения прав пользователей (AppArmor, SELinux) и др. Но такой вид анализа требует настройки специалистом, а не рядовым пользователем. Более того, пользователи зачастую сами виновны в том, что буквально отдают в руки злоумышленникам важную информацию. Но это не значит, что мы не должны из-за этого её защищать.

Как модель машинного обеспечения может гарантировать информационную безопасность?

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

При этом надо понимать, что гарантия - это в любом случае определённая вероятность. Успешность стратегий защиты информации в основе своей определяется долей вероятности, что атаки будут безуспешны. Если такая вероятность достигнет 95%-99%, мы будем считать, что наша модель выполняет обозначенные функции.

Классификация программных угроз

Угрозы могут быть доставлены на компьютер следующими способами:

1. В виде скомпилированной для конкретной платформы и ОС программы, представленной бинарным кодом, где есть конкретные строки и обращения к известным системным библиотекам и ядру, способные нанести вред.
2. В виде скомпилированной программы, способной выполнять небезопасные паттерны, определяемые интерпретируемым кодом, данными из Сети и/или пользовательским поведением.
3. В виде программы, которая выполняет внешне безопасные команды, но основана на знании злоумышленниками уязвимостей ОС и прикладных программ и библиотек.

Анализ статических программ (п. 1)

Есть два способа проверить статические программы на наличие угроз: проанализировать код, представленный в скомпилированном варианте - и сэмулировать выполнение данной программы.

Анализ бинарного кода, направленный на выявление небезопасных паттернов, может иметь невысокую эффективность по разным причинам; например, программный код могли обфусцировать, чтобы паттерны невозможно было выявить. В то же время ни анализ бинарного кода, ни эмуляция выполнения программы не могут предусмотреть все возможные ветвления программы, и, следовательно, не могут найти ни искомых паттернов, ни - во втором случае - даже завершить эмуляцию программы.

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

Анализ динамических программ (п. 2)

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

Анализ программ, использующих уязвимости системы (п. 3)

Анализ таких программ и вовсе усложняется благодаря тому, что они вообще не выполняют внешне вредоносных действий: их осуществляют прикладные и системные программы, которые считаются безопасными по умолчанию или же не могут быть безопасными по определению и поэтому игнорируются.

Дело в том, что ядро операционной системы должно для нормального функционирования обладать всеми возможностями, в том числе составляющими небезопасные паттерны. Но, опять-таки, использование таких возможностей в определённой последовательности и приводит к нарушению ИБ. Например, только за 2019 год Red Hat исправил более 1000 CVE в своём дистрибутиве RHEL, согласно их отчёту Product Security Risk Report.

Большинство системных программ используют прямые вызовы ядра и системных библиотек для взаимодействия с сетевыми и физическими устройствами. Для защиты от уязвимостей разные ОС используют разные средства, например, в Android версии 11 и выше используют разрешения приложений (так как все приложения для этой ОС пишутся на Java и Kotlin и выполняются при помощи виртуальных машин Dalvik и ART), чтобы ограничивать доступ приложений к тем функциям, к которым они не должны иметь доступа. В то же время Windows не имеет такого механизма (у Windows-программ нет манифеста, в котором декларировались бы разрешения, требуемые разработчиками для обеспечения работоспособности программы). Более того, даже декларирование разрешений не защищает конечного пользователя после того, как он предоставил вредоносному приложению требуемые разрешения. А в самой ОС Android не запрашиваются разрешения для получения фингерпринта устройства, которое позволило бы практически однозначно определить конкретное физическое устройство, и передачи его по Интернету третьим лицам в целях слежения.

Более того, самый уязвимый элемент информационной безопасности - это зачастую сам пользователь компьютера, и его действия могут вследствие незнания или иных причин нанести гораздо больший вред, чем эксплуатация уязвимостей программных систем. Большинство атак за первые три квартала 2022 года были успешно осуществлены именно при помощи навыков социальной инженерии.

Анализ реального времени (RTA)

Как мы выяснили, для того, чтобы обеспечить защиту от угроз, недостаточно применять пассивный анализ. Гораздо важнее поставить акцент на активном анализе, так как в этом случае:

1. Мы можем блокировать выполнение деструктивной части программы, при этом задействуя её безопасную часть.
2. Проблемы с ветвлением бинарного кода и пользовательским вводом решаются прямо в тот момент, когда приходит следующая команда на процессор, потому что к этому моменту все необходимые данные программы имеются.

Таким образом, активный анализ - RTA - позволяет нам эффективно противостоять угрозам в статических и динамических программах, не использующих уязвимости системы. В следующем же разделе мы рассмотрим проблемы, связанные с этими уязвимостями.

Создание комплекса защиты информации

Продукт, способный обеспечивать его пользователям надёжный уровень кибербезопасности, должен решать проблему оценки вероятности. Поскольку проектировать планируется именно продукт, производящий RTA, вероятность будет означать безопасность выполнения предложенной команды.

Что немаловажно, видов и типов угроз бесчисленное множество, хотя они и совершаются в ограниченном пространстве на ограниченном числе физических устройств одного компьютера. Например, в начале 2022 года один специалист смог передавать данные с компьютера, изменяя скорость вращения кулера и фиксируя итоговую вибрацию на диктофон. Это не говоря уже о том, что двумя годами ранее хакеры научились определять нажимаемые на клавиатуре клавиши благодаря характерному звуку нажатия.

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

Как оценить успехи нашей ML-модели?

Одним из ключевых факторов оценки работоспособности модели машинного обучения является точность модели. При этом второй ключевой фактор - это переобученность. Как правило, обучение на наборе данных строится путем разделения набора на маленькую обучающую выборку и остальную, тестовую выборку. Если точность на обучающей выборке гораздо больше, чем на тестовой, это позволяет судить о том, что модель переобучена, т.е. попросту запомнила обучающую выборку, а вовсе не выявила правила, по которым она классифицируется. В процессе обучения модели мы должны стремиться:

1. Набрать большой набор данных (чем больше - тем лучше).
2. Оптимально разделить набор на выборки.
3. Следить за тем, чтобы точность модели увеличивалась, а переобученность - уменьшалась.

Архитектура комплекса защиты информации

Комплекс ЗИ должен состоять как минимум из двух компонентов:

1. Пассивный анализатор - собирает данные о программе перед её запуском.
2. RTA-модель - программа, принимающая на вход данные с пассивного анализатора и оценивающая действия, затрагивающие информационную безопасность в реальном времени.

Архитектура ML-модели

Предлагается разработать рекуррентную нейронную сеть, состоящую из двух ступеней:

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

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

Вторая ступень нейронной сети встраивается между процессом и операционной системой, постоянно анализируя действия программы. Входные данные - m + k + 1 вероятностных значений и одно числовое значение, где m - число установленных категорий в классификации приложений; k - набор чисел, служащих буфером для запоминания предшествующих команд; одно вероятностное значение - оценка вероятности угрозы, одно числовое значение - код следующей команды. Выходные данные - k + 1 вероятностных значений, где k - обновлённый буфер истории команд, а ещё одно вероятностное значение - наша итоговая оценка вероятности угрозы, которая сообщает, насколько небезопасно выполнять следующую команду.

Буфер истории команд позволяет запоминать и искать паттерны, не используя для этого вектор истории команд с изменяемым размером.

В зависимости от архитектуры комплекса ЗИ нейросеть будет анализировать каждый процесс отдельно либо дополнительно отслеживать взаимодействие процессов и выявлять комплекты программ, каждая из которых вносит свой вклад в атаку. Также, помимо программного средства, комплекс может представлять из себя аппаратно-программное средство, так как для анализа большого числа команд нужна дополнительная мощность. Ещё расположение комплекса в отдельном аппаратном устройстве, вероятно, снизит его собственную уязвимость.

Способы обучения

Для обучения ML-модели предлагается составить набор безопасных и заражённых программ, чтобы провести обучение с подкреплением. Ещё один вариант - создать генератор заражённых программ, чтобы провести автоматизированное генеративное обучение.

Предполагаемые минусы комплекса в качестве антивируса

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

Приложение А. Определения

Активный анализ, или анализ реального времени (RTA) - анализ вредоносной активности в реальном времени.

Пассивный анализ - анализ бинарного кода после получения программы и перед её запуском.

ML-модель - с англ. machine learning - модель машинного обучения, программа, способная самостоятельно выводить закономерности на основе входящих данных.

Источники

1. Machine Learning and Machine Safety - Виктор Шамшин, Сборник трудов V Международной студенческой конференции «Science, Culture and Youth»
2. Как работают антивирусы. Методы детектирования вредоносных программ - Валентин Холмогоров, Xakep.ru
3. Recurrent Neural Networks (RNNs): A gentle Introduction and Overview - Robin M. Schmidt, arXiv.org
4. Neural Dynamics on Complex Networks - Chengxi Zang & Fei Wang, arXiv.org

А можно ли этого избежать как-то?

Мне, в сущности, нужно было вызвать обработку ввода, которая выдавала ответ на экран через сигнал. Если в одном из вариантов ответа находился скрипт, я должен подождать его выполнения.

Официальный C API от Python поддерживал только прямой вызов функции из модуля, не асинхронный, поэтому пришлось подумать о том, как вынести этот вызов в отдельный поток. И даже здесь оказалось не всё так однозначно: при инициализации среды выполнения Python ориентировался только на главный поток, и чтобы получить доступ к интерпретатору в другом потоке, нужно было вызвать пару методов - и при этом гарантировать, что программа не пытается запустить такой же поток где-нибудь ещё.

Извне функции обертка приняла вид цикла, который каждые 0.3 секунды опрашивает результат, и если ответа нет, вызывает функцию обработки событий event loop'а...

И вот проблема!

1. Если пользователь отправит ещё одно сообщение, которое вызовет скрипт, то либо произойдет ошибка segfault из-за повторного обращения к интерпретатору из другого потока, либо deadlock из-за ожидания разблокировки мьютекса на интерпретаторе, потому что он находится в том же потоке.
2. А если функция не станет ждать разблокировки мьютекса, то данные будут утеряны.

Решение нашлось ровно в том месте, где ожидается от Qt. Ведь, как говорится, клин клином вышибают.

Сигналы и слоты для обработчика

Нам, так или иначе, нужен обработчик задач. Пусть запрос на выполнение скрипта будет записан в структуру PythonTask, тогда мы сможем создать метод, который делает две важные вещи:

1. Если мьютекс интерпретатора заблокирован, мы добавляем задачу в список задач и завершаем выполнение функции.
2. Если мьютекс разблокирован, то, пока список задач не пуст, мы обрабатываем их все и отправляем при помощи сигналов, причём каждый ожидаемый промежуток времени запускаем обработку событий Qt.

Как слотам понять, ответ на какую задачу прислал обработчик? Выход простой - добавить уникальный идентификатор к задаче перед отправкой в обработчик.

Общие черты разработки в Qt

Чтобы реализовать одновременно отзывчивость интерфейса и возможность обработки сложных задач, нужно:

• выделять сложные задачи в потоки;
• динамически опрашивать потоки о завершении;
• в перерывах вызывать обработку событий Qt.

Отличие от Rust

Qt не пытается при помощи макросов уйти в метапрограммирование потоков - например, в том же tokio асинки имеют свою низкозатратную реализацию, причём на уровне программы мы пишем код, будто каждая функция будет выполняться в отдельном потоке, в то время как эта реализация просто прерывает выполнение функции в одном месте и потом возобновляет по мере получения результата. C++ так не делает, и поэтому все функции желательно завершать, передавая результаты event loop'у и используя для этого превосходный механизм сигналов и слотов.