В продолжение предыдущей статьи Передовые технологии на службе СЭД рассмотрим современные подходы к обеспечению корпоративной безопасности и ожидаемые риски у компаний в России.

Аннотация

Что такое безопасность уровня Enterprise? Встречается огромное разнообразие схем конфигурации безопасности инфраструктуры. Например: валидация и кэширование токена только в сервисе Gateway с прямой отправкой логина и списка ролей сервисам или ретрансляция токена с Gateway в сервисы для активации функций Spring Security через распаковку токена в логин и роли с проверкой только подписи токена и т.д. и т.п.

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

В статье рассматриваются основные аспекты конфигурирования корпоративной безопасности с поддержкой высоких нагрузок в реактивном стеке технологий. Подробно описана модель безопасности attribute-based access control (ABAC), которая применяет совокупность абстрактных правил к определённому типу действий с учётом роли, при необходимости.

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

Введение

Начнём с рассмотрения основополагающей на данный момент модели безопасности ABAC в сравнении с классической моделью role-based access control (RBAC).

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

RBAC оперирует ролями и группами ролей. Каждая роль напрямую привязана к действию, что приводит к созданию большого количества ролей (роль менеджера головной организации, роль менеджера филиала, роль менеджера подразделения филиала – разные сущности в силу функциональных различий).

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

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

Целевое направление применения ABAC – описание политик безопасности филиальной системы с полным контролем доступа до любого уровня вложенности и сложности описания правил. Все правила ABAC описываются в виде SpEL-выражений и в отличии от RBAC хранятся в базе данных, где соответственно легко поддаются анализу и модификации.

Можно отметить интересный факт связанный с переходом информационной безопасности от модели RBAC к ABAC – на первом этапе каждая политика будет содержать одно правило.

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

В итоге, реализована библиотека Reactive Spring ABAC Security с открытым исходным кодом на GitHub, обладающая рядом свойств: как гибкость в настройках, мощь в широких возможностях и скорость в работе. Библиотека опубликована в Maven Central:

<dependency>
    <groupId>io.github.sevenparadigms</groupId>
    <artifactId>reactive-spring-abac-security</artifactId>
    <version>1.0.2</version>
</dependency>

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

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

Совсем необязательно поднимать дополнительный корпоративный SSO-сервер аутентификации типа Keycloak для задач такого рода, когда скорость реализации и простота развёртывания выходят на передний план – ведь для таких задач достаточно фрилансера, без отрыва внутренних ресурсов от основных задач.

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

Основные аспекты реализации

Рассмотрим основные моменты при настройке конфигурации безопасности Spring Security:

@Bean
fun securityWebFilterChain(
    http: ServerHttpSecurity,
    authenticationWebFilter: AuthenticationWebFilter,
    abacRulePermissionService: AbacRulePermissionService,
    expressionHandler: DefaultMethodSecurityExpressionHandler
): SecurityWebFilterChain {
    expressionHandler.setPermissionEvaluator(abacRulePermissionService)
    http.csrf().disable()
        .headers().frameOptions().disable()
        .cache().disable()
        .and()
        .exceptionHandling().authenticationEntryPoint(unauthorizedEntryPoint())
        .and()
        .authorizeExchange()
        .pathMatchers(HttpMethod.OPTIONS)
        .permitAll()
        .and()
        .requestCache().requestCache(NoOpServerRequestCache.getInstance())
        .and()
        .authorizeExchange()
        .matchers(EndpointRequest.toAnyEndpoint())
        .hasAuthority(Constants.ROLE_ADMIN)
        .and()
        .authorizeExchange()
        .pathMatchers(*Constants.whitelist).permitAll()
        .anyExchange().authenticated()
        .and()
        .securityContextRepository(NoOpServerSecurityContextRepository.getInstance())
        .addFilterAt(authenticationWebFilter, SecurityWebFiltersOrder.AUTHORIZATION)
        .httpBasic().disable()
        .formLogin().disable()
        .logout().disable()
    return super.tryAddTokenIntrospector(http).build()
}

Строка expressionHandler.setPermissionEvaluator(abacRulePermissionService) включает функционал ABAC. Все правила ABAC представляют собой компилируемые и кэшируемые SpEL-выражения, предоставляя полную свободу в предикатах. Подробное описание подключения ABAC в разделе настройки безопасности на стороне клиентского сервиса через файл конфигурации application.yml

По умолчанию, при первом запросе клиента, Spring создаёт web-сессию для кэширования сессионных переменных, результата запросов и сбора различных данных при взаимодействии с клиентом в рамках одной сессии. Данный подход устарел, даже с применением Redis или Hazelcast – сессии занимают значительный объем памяти и вся логика вокруг сессий не имеет перспектив, не говоря уже о проблемах утечки в реактивном стеке.

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

Следующей строкой отключаем поддержку сессий: securityContextRepository(NoOpServerSecurityContextRepository.getInstance())

В Webflux была проблема #7157 связанная с автоматическим кэшированием в сессиях, поэтому также отключаем сессионное кэширование строкой: requestCache().requestCache(NoOpServerRequestCache.getInstance()), для того, чтобы Webflux оперировал только кэшем уровня бизнес-логики и только в контексте потока исполняемого запроса.

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

Возможность кэширования токенов предусмотрена в библиотеке Spring OAuth2 через расширение OpaqueToken и кэширующий интроспектор NimbusOpaqueToken, который единожды валидирует токен в сервисе авторизации. Заменим интроспектор на свою реализацию, т.к. в нашей библиотеке не используются автоконфиги Spring OAuth2, не смотря на заимствование функционала, и включим в конфигурацию строкой: http.oauth2ResourceServer().opaqueToken().introspector(super.tokenIntrospector())

Пришлось создать боб билдера WebClient сразу по множеству причин:

@Bean
fun webClientBuilder(): WebClient.Builder = WebClient.builder()
    .clientConnector(
        ReactorClientHttpConnector(
            HttpClient.create(
                ConnectionProvider.builder("fixed")
                    .maxConnections(500)
                    .maxIdleTime(Duration.ofSeconds(30))
                    .maxLifeTime(Duration.ofSeconds(60))
                    .pendingAcquireTimeout(Duration.ofSeconds(60))
                    .evictInBackground(Duration.ofSeconds(120)).build()
            ).keepAlive(false)
        )
    )
    .exchangeStrategies(ExchangeStrategies.builder()
        .codecs { c: ClientCodecConfigurer ->
            c.customCodecs().register(Jackson2JsonDecoder(JsonUtils.getMapper()))
            c.customCodecs().register(Jackson2JsonEncoder(JsonUtils.getMapper()))
        }
        .build())
    .filter { clientRequest: ClientRequest, next: ExchangeFunction ->
        Mono.deferContextual { ctx: ContextView ->
            val requestHeaders = ctx.get(ServerWebExchange::class.java).request.headers.toSingleValueMap()
            val request =
                ClientRequest.from(clientRequest).headers { headers -> headers.setAll(requestHeaders) }.build()
            next.exchange(request)
        }
    }
    .codecs { it.defaultCodecs().apply { maxInMemorySize(16 * 1024 * 1024) } }

чтобы поправить таймаут соединения, решить проблему ограничения пула в 16 соединений, зарегистрировать настроенный ObjectMapper, включить ретрансляцию заголовков и увеличить размер буфера обмена – работа с WebClient с дефолтными настройками со временем может привести к ряду ошибок, в частности к 'Connection reset by peer'.

Также решилась проблема Netty с постоянным ростом незакрытых соединений при высокой нагрузке:

@Bean
fun nettyWebServerFactoryCustomizer() = WebServerFactoryCustomizer<NettyReactiveWebServerFactory> {
    it.addServerCustomizers(
        NettyServerCustomizer { server: HttpServer ->
            server.doOnConnection { connection: Connection ->
                connection.addHandler(
                    object : IdleStateHandler(0, 0, 0) {
                        override fun channelIdle(ctx: ChannelHandlerContext, evt: IdleStateEvent) {
                            ctx.fireExceptionCaught(
                                if (evt.state() == IdleStateEvent.WRITER_IDLE_STATE_EVENT.state())
                                    WriteTimeoutException.INSTANCE
                                else
                                    ReadTimeoutException.INSTANCE
                            )
                            ctx.write(CloseWebSocketFrame())
                            ctx.close()
                        }
                    }
                )
            }
        }
    )
}

Для удобства, помимо реактивного ExchangeHolder, был добавлен синхронный ExchangeContext, т.к. часто контекст безопасности используется в статических методах:

object ExchangeHolder {
    fun getHeaders(): Mono<MultiValueMap<String, String>> {
        return Mono.deferContextual { ctx: ContextView ->
            Mono.just(
                ctx.get(ServerWebExchange::class.java).request.headers as MultiValueMap<String, String>
            )
        }
    }

    fun getResponse(): Mono<ServerHttpResponse> {
        return Mono.deferContextual { ctx: ContextView ->
            Mono.just(ctx.get(ServerWebExchange::class.java).attributes[RESPONSE] as ServerHttpResponse)
        }
    }

    fun getUser(): Mono<User> {
        return Mono.deferContextual { ctx: ContextView ->
            ctx.get(ServerWebExchange::class.java).getPrincipal<Principal>()
                .cast(UsernamePasswordAuthenticationToken::class.java)
                .map { it.principal }
                .cast(User::class.java)
        }
    }
}

Настройка безопасности клиента

Рассмотрим файл конфигурации application.yml из демонстрационного проекта webflux-dsl-abac-example:

spring:
  r2dbc:
    url: r2dbc:postgresql://postgres:postgres@localhost/dsl_abac?schema=public
    pool:
      maxSize: 20
  main:
    allow-bean-definition-overriding: true
  security:
    abac.url: r2dbc:postgresql://postgres:postgres@localhost/abac_rules?schema=public
    iteration: 512
    length: 720
    secret: eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJ1c2VyIiwiYXV0aCI6IlJPTEVfVVNFUiIsImV4cCI6MTYzMDYxMDI5NX0.m0XU2NvGaAtzptgLfmptj3Fk7S1e1NrBTYTqBAjHoPI8lbRB7z3J52FiLRw-PUZPjQusDt19RszrUQDsZoVXeQ
    expiration: 1800
    X-User-Id: true
    skip-token-validation: true
    cache-token: true

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

С точки зрения атаки, когда вся безопасность сервисов вынесена в БД – возникает новая цель в виде таблицы с правилами. Сервисы могут читать свои правила из общей таблицы за счёт применения безопасности со стороны PostgreSQL защиты на уровне строк, когда пользователь БД может видеть только свои записи в режиме чтения. Если пароли сервиса скомпрометированы, то атакующий может увидеть правила безопасности сервиса и запланировать стратегию атаки для получения конфиденциальной информации.

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

Необязательные переменные iteration и length используются для генерации секретного ключа и соли системного пароля пользователя. Необязательная переменная secret используется как часть секрета для генерации пароля пользователя и токена. Переменная expiration имеет значение времени жизни токена в секундах.

Переменные iteration, length, secret являются критическими для безопасности и в общем, рекомендуется хранить все значения переменных окружения в сервере секретов типа HashiCorp Vault.

X-User-Id при значении true активирует Spring Security, когда ожидается в заголовке X-User-Id значение id пользователя, а в X-Roles массив ролей. Имя пользователя в Spring Security указывается как пустая строка, если отсутствует заголовок X-Login.

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

Необязательная переменная skip-token-validation при значении true активирует Spring Security, извлекая из токена имя пользователя и роли, где присутсвует единственная проверка на время жизни токена.

Такая же беззащитная конфигурация как и предыдущая, но позволяет передать сервису работу по распаковке токена вместо Gateway. Защищается с помощью Istio.

Необязательная переменная cache-token при значении true активирует Spring Security с полной валидацией токена и кэшированием данных токена. В случае, если в конфигурации не прописан путь до сервиса авторизации spring.security.introspection.uri, тогда ожидается, что токен каким-то образом уже лежит в текущем CacheManager – это удобно при кустомном способе авторизации пользователя, а иначе CacheManager используется для кластерного кэширования. Вместо пути до сервиса авторизации можно указать в переменной spring.security.jwt.key сохраненный в Base64 публичный ключ токена для проверки подписи.

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

Практическое применение ABAC

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

CREATE TABLE abac_rule
(
    id             uuid DEFAULT uuid_generate_v1mc() NOT NULL PRIMARY KEY,
    name           text,
    domain_type    text,
    target         text,
    condition      text
);

insert into abac_rule(name, domain_type, target, condition)
values('Test Rule', 'Dsl', 'action == ''findAll'' and subject.roles.contains(''ROLE_ADMIN'')', 'domainObject.sort == ''id:desc'''),
      ('IP Rule', 'Dsl', 'action == ''findAll'' and environment.ip == ''192.168.2.207''', 'domainObject.sort == ''id:desc'''),
      ('Query jtree not null Rule', 'Dsl', 'action == ''findAll'' and subject.roles.contains(''ROLE_ADMIN'')', 'domainObject.query == ''!@jtree'' and domainObject.fields ==''id''  and domainObject.sort == ''id:desc'''),
      ('Query equals jsonb field Rule', 'Dsl', 'action == ''findAll'' and subject.roles.contains(''ROLE_ADMIN'')', 'domainObject.query == ''jtree.name==Acme doc'' and domainObject.sort == ''id:desc'''),
      ('Query equals jsonb field in Rule', 'Dsl', 'action == ''findAll'' and subject.roles.contains(''ROLE_ADMIN'')', 'domainObject.query == ''jtree.name^^Acme doc'' and domainObject.sort == ''id:desc''');

Применение правила в аннотации над методом:

@PreAuthorize("hasPermission(#dsl, 'findAll')")
fun findAll(@PathVariable jfolderId: UUID, dsl: Dsl) 
                                         = objectService.findAll(jfolderId, dsl)

Как уже ранее указывалось, выражения ABAC в виде SpEL компилируется и кэшируются, довольно простым методом:

@Component
class ExpressionParserCache : ExpressionParser {
    private val cache: MutableMap<String, Expression> = ConcurrentHashMap(720)
    private val parser: ExpressionParser = SpelExpressionParser()

    @Throws(ParseException::class)
    override fun parseExpression(expressionString: String): Expression {
        return cache.computeIfAbsent(expressionString) {
            parser.parseExpression(it)
        }
    }

    @Throws(ParseException::class)
    override fun parseExpression(expressionString: String, 
                                 context: ParserContext): Expression {
        throw UnsupportedOperationException("not supported")
    }
}

Затем перегружается стандартный метод безопасности hasPermission:

@Service
class AbacRulePermissionService(
    private val abacRuleRepository: AbacRuleRepository,
    private val expressionParserCache: ExpressionParserCache,
    private val exchangeContext: ExchangeContext
) : DenyAllPermissionEvaluator() {
    override fun hasPermission(authentication: Authentication,
                               domainObject: Any, action: Any): Boolean {
        debug("Secure user %s action '%s' on object %s", authentication.name, action, domainObject)
        val user = authentication.principal as User
        return checkIn(
            AbacSubject(user.username, user.authorities.map { it.authority }.toSet()),
            domainObject,
            action as String
        )
    }

    private fun checkIn(subject: AbacSubject, domainObject: Any, action: String): Boolean {
        var result = false
        runBlocking {
            val context = AbacControlContext(
                subject, domainObject, action, 
                AbacEnvironment(ip = exchangeContext.getRemoteIp(subject.username))
            )
            result = abacRuleRepository.findAllByDomainType(domainObject.javaClass.simpleName)
                .filter { abacRule: AbacRule ->
                    expressionParserCache.parseExpression(abacRule.target).getValue(
                        context,
                        Boolean::class.java
                    )!!
                }
                .any { abacRule: AbacRule ->
                    expressionParserCache.parseExpression(abacRule.condition)
                        .getValue(context, Boolean::class.java)!!
                }
                .awaitFirst()
        }
        return result
    }
}

Сначала формируется контекст в виде модели AbacControlContext, содержащий поля subject с логином и ролями пользователя, domainObject – входящий объект, action – наименование правила и AbacEnvironment с текущей датой и ip клиента.

Как видно из кода, при поиске всех правил по атрибуту domain (берётся имя класса из domainObject), сначала фильтруем по SpEL выражению из атрибута target и если найдены правила, то по ним в атрибуте condition прогоняем итоговое SpEL выражение.

Для более подробного изучения применения ABAC следует изучить исходный код тестов демонстрационного проекта webflux-dsl-abac-example.

В тестовом окружении демо проекта в качестве используемой базы данных поднимается контейнер postgres-rum:latest – что невероятно удобно и практично:

private fun createContainer(): KContainer =
    KContainer(DockerImageName.parse("jordemort/postgres-rum:latest")
        .asCompatibleSubstituteFor("postgres"))
        .withDatabaseName("test-db")
        .withUsername("postgres")
        .withPassword("postgres")
        .withCreateContainerCmdModifier { cmd ->
            cmd.withHostConfig(
                HostConfig().withPortBindings(
                    PortBinding(
                        Ports.Binding.bindPort(5432), ExposedPort(5432)
                    )
                )
            )
        }
        .withReuse(true)
        .withCopyFileToContainer(
            MountableFile.forClasspathResource("init.sql"),
            "/docker-entrypoint-initdb.d/"
        )

А вот пример теста демо проекта, проверяющий потоковую изолированность извлечения контекста безопасности из реактивной цепочки:

@Test
fun `test Holder race condition by two users`() {
    val flux = Flux.range(1, 100)
        .parallel(10)
        .runOn(Schedulers.boundedElastic())
        .flatMap { rangeCount ->
            val testIp: String
            if (rangeCount % 2 == 0) {
                testIp = nonCorrectIp + rangeCount
                webClient.get()
                    .uri("dsl-abac/context")
                    .header(HttpHeaders.AUTHORIZATION, Constants.BEARER + adminToken)
                    .header(Constants.AUTHORIZE_IP, testIp)
                    .exchangeToMono { it.bodyToMono(List::class.java) }
                    .zipWith(Mono.just(testIp))
            } else {
                testIp = correctIp + rangeCount
                webClient.get()
                    .uri("dsl-abac/context")
                    .header(HttpHeaders.AUTHORIZATION, Constants.BEARER + userToken)
                    .header(Constants.AUTHORIZE_IP, testIp)
                    .exchangeToMono { it.bodyToMono(List::class.java) }
                    .zipWith(Mono.just(testIp))
            }
        }

    StepVerifier.create(flux)
        .expectNextCount(98)
        .expectNextMatches { it.t2 == it.t1[1] }
        .expectNextMatches { it.t2 == it.t1[1] }
        .thenCancel()
        .verify()
}

Системные риски безопасности

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

Microsoft, согласно статьям тех лет, и на самом деле точно не известно правда это или вымысел – до 2013 года встраивала в свои ОС дыры и сообщала о выявленных спецслужбам США. Диванные эксперты считают, что сейчас взаимодействие всех корпораций со спецслужбами происходит на коммерческой основе для формирования баланса между коммерческим имиджем и уровнем технологичности ведения разведки.

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

Возможно, в результате данного инцидента и скорее всего, с текущего 2022 года – правительственные учреждения, подрядчиковые организации и финансовые институты Китая начнут работать с маршрутизаторами, серверами и операционными системами отечественного производства.

Есть интересная оборотная сторона, согласно материалам Bloomberg от которых сразу же отказались – с 2013 по 2015 года в Китае было произведено десятки тысяч серверов Supermicro с дополнительным чипом 2х3 мм, которые в массовом порядке поставлены сотням компаний по всей планете. Из них 7000 серверов были установлены в Apple. Также сервера доставили подрядчику Министерства обороны США Elemental, который устанавливал их в бортовые сети боевых кораблей ВМФ, центры управления беспилотников ЦРУ, центры обработки данных Министерства обороны, NASA, обе палаты Конгреса, подразделение внутренней безопасности Госдепа, а также в Amazon.

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

Опять же по тем же отозванным материалам Bloomberg, в 2015 году новое подразделение Amazon Web Services (AWS), созданное для нужд ЦРУ, наняла стороннюю компанию для проверки безопасности серверов, поставляемые Elemental, где обнаружили чип вне оригинальной конструкции плат Supermicro. Apple в том же году демонтировал 7000 серверов Supermicro и разорвал контракт на поставку еще 30 тыс. серверов Supermicro.

А потом, в сентябре 2015 года, КНР и США заключили договоренность о правовой поддержке защиты интеллектуальной собственности и увеличении поставок сетевого оборудования из США в Китай. Если эта история на самом деле имело место, то тогда она весьма и весьма поучительная – не стоит шутить ни с каким централом.

В России же налажен выпуск отечественных маршрутизаторов на процессоре «Байкал-Т1», но по ним пока нет эксплуатационной экспертизы и соответственно компании не готовы к переходу. Также пока нет отечественной серверной ОС и все на свой страх и риск продолжают использовать Windows Server и AWS от Amazon, не смотря на высокие корпоративные стандарты онных.

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

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

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

К слову, Россия производит модульную военную технику, отчасти чтобы исключить возможность использования дополнительного чипа, чтобы заказчики могли устанаваливать свои модули в самые чувствительные места самолёта, корабля, танка или средств ПВО.

Основным способом защиты от системных угроз является внедрение искусственного интеллекта в машрутизаторы, в средства мониторинга сетей, в кластер Kubernetes, в Spring Security для автоматичекого блокирования необычной активности. А в случае централизованного управления – блокировка в остальных случаях будет мгновенной по базовым признакам без анализа поведения.

Резюме

Расширение модели безопасности до ABAC не несёт дополнительных затрат, т.к. RBAC естественным образом интегрируется и информационная безопасность предприятия становится управляемой. Библиотека активно используется и дорабатывается, отчего данная статья будет потихоньку дополнятся. Библиотека уже на текущем этапе представляет стабильный и быстрый функционал. Стоит подключить Z Garbage Collector для хорошего улучшения производительности реактивного стека.

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

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

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

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

Интересно было бы строить совместные кластера с Китаем и Индией, как с ближайшими союзниками, для выстраивания многополярного технического сотрудничества в охвате сотен стран, в частности стран Африканского региона. А финансовым институтам России начать строить партнёрские отношения с IT-гигантами Alibaba и Xiaomi для обоюдного обогащения компетенциями и совместного развития opensource-проектов, ведь на текущий момент, все opensource-проекты мирового уровня, признанные в своих областях стандартами де-факто – сосредоточены в одной Кремниевой долине.

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