Russia to Mandate Gosuslugi Authentication for Hosting Providers, Further Reducing Anonymity in Runet
The Russian Ministry of Digital Development (MinTsifry) has resumed efforts to tighten control over hosting providers by proposing mandatory client identification through the Gosuslugi portal. The initiative would apply not to selected services but to virtually all hosting offerings, requiring every customer to authenticate via a confirmed ESIA account.
Under the proposed rules, each allocated IP address must be tied to a specific individual with a verified government-linked profile. Current identification methods—such as email addresses, bank cards, or other indirect verifications—are considered insufficient by regulators seeking greater transparency across the Russian internet segment known as Runet.
This policy builds directly on measures introduced in September for domain registrations. Owners of domains in the .ru, .рф, and .su zones must now confirm their identity through ESIA both when registering new domains and when renewing existing ones. Regulators intend to extend the same verification standard to hosting services.
Reactions within the hosting industry remain sharply divided. Turbo Cloud supports the change, arguing that mandatory identification will help combat phishing attacks and fraudulent schemes. The company has already integrated ESIA authentication and states that the associated expenses remain manageable for providers.
Other companies express more cautious or negative views. Runity estimates that preliminary implementation costs will reach at least 5 million rubles. RUVDS warns that the new requirements could severely damage the retail segment of the market, particularly affecting students, independent developers, and private individuals who may find the additional Gosuslugi verification step overly burdensome.
According to RUVDS assessments, providers could lose between 20% and 35% of such retail customers. These users are expected to migrate not to offline alternatives but to foreign hosting providers operating outside Russian jurisdiction.
A separate concern involves foreign clients. Without an alternative identification mechanism, non-Russian users may lose access to hosting services, servers, and domains. Overall, the push for greater transparency risks accelerating both the decline of online anonymity and the outflow of clients beyond Russia’s borders.
Related articles
Kubernetes Audit Policy Review: Checklist Targets Common Blind Spots in Rules
An experienced Kubernetes administrator shared a detailed review process for audit policies that often remain untouched for years after initial deployment. The 580-line policy was rebuilt using the Kubernetes Threat Matrix from RedGuard as the primary reference. The author highlights recurring issues such as outdated exceptions, missing coverage for new components, and legacy comments that obscure actual security intent. The resulting checklist focuses on principles rather than cluster-specific findings to help other teams perform effective policy audits. Key recommendations address rule completeness, exception management, and periodic full-scale reviews instead of incremental patching. The approach aims to restore audit policies as active security controls rather than accumulated technical debt.
Avoiding a Leaky Kubernetes Audit Policy: Real-World Configuration Breakdown
Kubernetes Audit Policy is typically configured once during cluster setup and then left untouched for years while accumulating exceptions for new components. Over time the policy stops functioning as a security control and instead becomes an archaeological layer of outdated comments such as "# temporary, TODO remove" that date back three years or more. The author recently reviewed their own 580-line configuration file that had been assembled from multiple sources. Primary reference was the Kubernetes Threat Matrix, which explains why many rules are designed to detect security-relevant actions rather than simply reduce log noise. Examples include targeted monitoring of RBAC modifications and deletion of events. The article emphasizes the need for periodic full reviews instead of incremental patching to maintain effective detection coverage.
CryptoPro Develops CryptoPro-Browser with Russian Cryptography for FSB Compliance
CryptoPro is creating its own browser called CryptoPro-Browser as part of the CryptoPro CSP 6.0 cryptographic information protection system. The product will include built-in cryptographic tools, support for the company's plugin, and TLS connections using Russian cryptographic algorithms. The development follows Google's removal of the CryptoPro extension from the Chrome Web Store in February 2025, which left new users without an easy installation method. The project has been coordinated with the FSB of Russia and targets scenarios requiring compliance with Russian information security regulations. CryptoPro plans to incorporate experience from its earlier Chromium-Gost project started in 2017, while also recommending Yandex Browser as an alternative. Analysts estimate the development cost at several tens of millions of rubles, with the main focus on corporate customers needing certificate management and specialized support.
Yandex 360 Email Archive Documentation Shows Search Snapshots and Former Employee Log Filters
The Yandex 360 administrator guide describes the email archive as a tool that stores copies of all messages sent and received by employees on the organization's domain. Two specific statements in the documentation indicate that each saved search returns a static snapshot that does not update automatically when new mail arrives, requiring manual cloning or recreation of the search to obtain current results. The same documentation states that the action log records every operation performed in the archive, yet the employee filter in the log interface only displays currently active accounts, making it impossible to select a former administrator by name. API 360 currently provides no documented endpoints for creating, executing, or retrieving archive searches, leaving all operations dependent on the web console. Additional notes clarify that messages remain available after an account is blocked but disappear once the account is deleted, and that messages removed before the archive was enabled cannot be recovered. These documented behaviors directly affect incident response and offboarding procedures that rely on historical email retrieval and audit trails.