Possible New Result in Quantum Factorization

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/03/possible-new-result-in-quantum-factorization.html

I’m skeptical about—and not qualified to review—this new result in factorization with a quantum computer, but if it’s true it’s a theoretical improvement in the speed of factoring large numbers with a quantum computer.

From legacy architecture to Cloudflare One

Post Syndicated from Warnessa Weaver original https://blog.cloudflare.com/legacy-to-agile-sase/

For a network engineer, the cutover weekend is often the most stressful 48 hours of their career. Imagine a 30,000-user organization attempting to flip 1,000+ legacy applications from fragmented VPNs to a new architecture in a single window. The stakes are immense: a single misconfigured firewall rule or a timed-out session can halt essential services and lead to operational gridlock.

This “big bang” migration risk is the single greatest barrier to Zero Trust adoption. Organizations often feel trapped between an aging, vulnerable infrastructure and a migration process that feels too risky to attempt.

Cloudflare and Technology Solutions Provider CDW are changing this narrative. We believe that a successful transition to SASE (Secure Access Service Edge) shouldn’t feel like a leap into the dark. By combining Cloudflare’s global Zero Trust platform with CDW’s experience navigating the industry’s most complex deployment failures, we provide the strategic roadmap to de-risk the journey. We don’t just move your “plumbing” — we ensure your legacy debt is transformed into a modern, agile security posture without the downtime.

Leveraging partner expertise to avoid migration traps

Traditional migrations often fail because they treat the network as simple plumbing rather than a complex ecosystem of applications. Without a granular strategy, many organizations fall into the “lift and shift” trap — attempting to move hundreds of applications simultaneously without understanding their back-end dependencies.

To avoid this, CDW uses a risk-aware, tiered methodology. This approach categorizes every application in your environment by its technical complexity. We move simple, modern apps first to build momentum while saving complex, legacy systems for a more controlled, later stage.

A recent large-scale public sector project serves as a cautionary example of what can happen without this structure. In this case, a team attempted to migrate 500 applications at once. Because they lacked a tiered methodology to prioritize their 4,000+ applications, the move led to systemic service disruptions.

CDW’s role is to act as the architect that prevents these failures. CDW strategists, many of whom are former security practitioners, analyze these industry-wide failure points to identify recurring anti-patterns that derail Zero Trust journeys and build a more resilient migration blueprint. By treating migration as an application modernization project rather than a single connectivity swap, CDW ensures that security requirements are built into the foundation of the move rather than bolted on as an afterthought.

Modernizing legacy apps with Cloudflare Access

To move away from the all-or-nothing risks of the past, we start with the foundation of the solution: Cloudflare Access. Before we look at how to migrate complex legacy applications, it’s important to understand the value of the platform itself. Cloudflare Access replaces the broad, vulnerable perimeter of a traditional VPN with a Zero Trust model. Instead of granting a user access to an entire network segment, Access evaluates every single request based on identity, device posture, and other contextual signals. This significantly reduces the attack surface and prevents the lateral movement that leads to the kind of systemic outages we discussed earlier.

Once this security layer is in place, we can begin “wrapping” legacy applications in Cloudflare Access. This allows us to modernize the security posture of an old app without actually rewriting its code.

We do this wrapping in Cloudflare Access using a specific logic:

  • Problem: A legacy application with no built-in Multi-Factor Authentication (MFA) is exposed via a standard VPN, creating a high-risk entry point for attackers.

  • Mitigation: Using Cloudflare Tunnel, we create an outbound-only connection with both Single Sign-On (SSO) and MFA built-in. This effectively hides the application from the public Internet, as it no longer has a public IP address to scan or attack.

  • Policy: We then apply a Cloudflare Access policy at the edge. This requires an endpoint hardware-based MFA check and a device health scan before a single packet ever reaches your server.

By using this wrapping technique, CDW and Cloudflare make it possible for organizations to migrate at their own pace. You get the immediate security benefits of a modern cloud environment, while your legacy apps continue to run safely in the background.

Pre-migration audit

Before launching a pilot, IT leaders must audit the environment for architectural readiness, ensuring legacy systems are technically compatible with modern security protocols. “For large deployments, we focus on application modernization,” says Eric Marchewitz, a security solutions executive at CDW. “Many legacy applications could break if least privilege access was applied without proper preparation.”

1. Architectural & identity assessment

  • Determine identity providers: Confirm which applications rely on a federated Identity Provider (such as Okta) versus those using legacy local directories.

  • Map dependencies: Document backend database and API dependencies for each application to prevent service interruptions. This data identifies the hidden API calls that typically break during a cutover if service token-based Tunnel connectivity is not maintained on the backend.

2. Establish firebreak

Separate the project into a Strategy Group (focused on security standards) and an Implementation Group (focused on efficiency). This ensures that high-level security requirements, like those needed to prevent lateral movement, are not bypassed for the sake of deployment speed.

3. Persistent session stress test

Identify applications using legacy architectures to maintain session persistence and avoid connection drops during cellular tower switching. Cloudflare’s architecture, supported by Dynamic Path MTU Discovery (PMTUD), maintains a persistent session at the edge even as the client IP changes. Identifying these users during the audit allows us to displace expensive, rigid legacy hardware with a modern, single-pass architecture.

4. Categorization & timeline setting

Once complete, the remaining stack is tiered to set realistic implementation timelines:

Application Tier

Description

Estimated Migration Effort

Tier 0 (Modern SaaS Apps)

Native SAML/OIDC support so Cloudflare acts as a clientless identity provider proxy during authentication

1–3 hours per app

Tier 1 (Internal Web Apps)

Standard identity headers and modern web protocols support a clientless reverse proxy deployment with Cloudflare Tunnel 

3–6 hours per app

Tier 2 (Non-Web Client-Server Apps)

Specific port/protocol support or thick-client configurations required so both Cloudflare One Client and Cloudflare Tunnel deployments are used

4–8 hours per app

Tier 3 (Legacy Enterprise Apps)

Complex server-side connectivity (e.g. peer-to-peer, bidirectional) or back-end dependency requirements so Cloudflare Mesh or WAN deployments may complement Cloudflare Tunnel to support.

1–3 days per app; may require code revisions

The roadmap to escape velocity

To achieve “escape velocity” from legacy hardware, CDW follows a phased rollout that prioritizes coexistence over replacement.

  1. Phase 1: Strategy & Infrastructure: Formation of strategy and implementation teams. This phase includes identifying CDW strategists — former CISOs and architects — to act as peer sounding boards.

  2. Phase 2: Pilot Rollout: Deployment of the Cloudflare One Client to a pilot group of employees. During this phase, we address common friction points like the “latency tax,”  ensuring performance doesn’t compromise security.

  3. Phase 3: Production Scaling: Full scaling across the organization. We maintain a dual-client period where users run both legacy VPN and Cloudflare Access in tandem, ensuring a safe rollback path and an easier end-user transition to the new Zero Trust approach.

Performance as a security feature

Cloudflare’s single-pass architecture runs every security check simultaneously. 

“When we talk to customers about the connectivity cloud, the most impactful change isn’t just the modern security posture. It’s the operational velocity,” notes Annika Garbers, Head of Cloudflare One GTM. “Moving to a single control plane allows a security team to stop being a bottleneck.”

By building on a post-quantum encrypted foundation, we ensure this bridge is future-proofed against the next generation of threats.

Build your bridge with Cloudflare One’s agile SASE

Modernization is about building a bridge, not a “big bang.” This methodology is refined through our Partner Technical Advisory Board, where partner feedback informs our product roadmap directly. By focusing on application modernization and a phased rollout, organizations can regain architectural control and eliminate the fragmentation penalty for good.

The combination of Cloudflare’s SASE platform and CDW’s migration expertise provides a safety net for the journey. You get the immediate security benefits of identity-based access and phish-resistant MFA, without the operational gridlock of a massive, unmapped cutover.

The goal isn’t just to move your applications to the cloud. It’s to ensure that when you get there, your environment is more resilient, more visible, and significantly harder to breach.

Ready to de-risk your journey to a zero trust architecture? Use CDW’s Zero Trust Maturity Assessment to identify the hidden dependencies in your environment. Reach out to a Cloudflare One expert to start your transition with a proven blueprint.

Kernel prepatch 7.0-rc4

Post Syndicated from corbet original https://lwn.net/Articles/1062952/

Linus has released 7.0-rc4 for testing.

Then Thursday hit with the networking pull. And then on Friday
everybody else decided to send in their work for the week, with a
few more trickling in over the weekend. End result: what had for a
short few days looked like a nice calm week turned into another
“bigger than usual” release candidate.

To be fair, that “almost everything comes in at the end of the
week” is 100% normal, and none of this is surprising. I was
admittedly hoping that things would start to calm down, but that
was not to be.

I no longer really believe that it was the one extra week we had
last release cycle: I’m starting to suspect it’s the psychological
result of “hey, new major number”, and people are just being a bit
more active as a result.

Deploy AWS applications and access AWS accounts across multiple Regions with IAM Identity Center

Post Syndicated from Alex Milanovic original https://aws.amazon.com/blogs/security/deploy-aws-applications-and-access-aws-accounts-across-multiple-regions-with-iam-identity-center/

If your organization relies on AWS IAM Identity Center for workforce access, you can now extend that access across multiple AWS Regions with multi-Region replication. Previously, AWS access portal was only available in one Region, when you add an additional Region, users get an active access portal endpoint there. If the primary Region experiences a disruption, they can continue working through the additional Region. This enhancement also enables you to deploy AWS managed applications in additional Regions closer to your users, which reduces latency and helps meet regional compliance requirements. Meanwhile, you maintain centralized control by managing Identity Center configurations from the primary Region.

In this post, you’ll learn how to configure multi-Regions support, including multi-Region replication, encryption setup, adding Regions, updating your identity provider (IdP), and testing the setup end to end.

Prerequisites and considerations

Before enabling multi-Region support, confirm your environment meets these requirements and understand how this change will affect your existing setup.

Considerations

Keep the following limitations in mind before you begin:

  • IAM Identity Center account instances don’t support multiRegion replication.
  • Microsoft Active Directory and IAM Identity Center directory as identity source aren’t supported for multi-Region replication.
  • AWS opt-in Regions aren’t supported.
  • The AWS access portal in additional Regions doesn’t support the custom alias (in other words, customer-chosen subdomains).
  • AWS account access through additional Region relies on already provisioned permissions; new permission set assignments and group memberships can be managed only in the primary Region and are then automatically replicated to additional Regions.

Walkthrough

To set up multi-Region support, you’ll follow three steps: creating and configuring a customer-managed KMS key with Identity Center, enabling the additional Region in the Identity Center console, and updating your identity provider with the new regional URLs and bookmark applications.

Important: Your Identity Center instance operates on a primary-replica model where instance-level configuration changes must be made in the primary Region, while additional Regions receive read-only replications of your settings and provide Region-local access for your workforce. In this example, you will use Okta as your external IdP, with N. Virginia (us-east-1) as the primary Region and Frankfurt (eu-central-1) as the additional Region.

Before you start, ensure that you’re signed in to the console as an administrator in the same account and Region where your Identity Center instance resides.

Create and configure multi-Region customer-managed KMS keys with Identity Center

First, you must set up a multi-Region customer-managed KMS key with Identity Center in your primary Region and replicate it to additional Regions where you plan to replicate Identity Center. Identity Center uses customer-managed KMS keys for encryption of your identity data such as user attributes. Because the same key material must be available in each Region, you’ll create a multi-Region key — complete this step in the AWS Organizations management account. Before proceeding, confirm that your currently deployed AWS managed applications support customer-managed KMS keys with Identity Center. Each AWS KMS key has usage and storage cost, see AWS KMS pricing page for details.

1. Create the multi-Region customer-managed KMS keys in your primary Region and add it to your Identity Center instance
Follow the blog AWS IAM Identity Center now supports customer-managed KMS keys for encryption at rest, ensuring that you choose Multi-Region Key in Part 1: Create the key and define permissions.

For guidance on configuring your key policy, see the KMS key policy examples for common use cases in the Identity Center User Guide, which provides example policies you can adapt for your specific requirements.

2. Create replica keys in additional Regions
After completing the primary Region setup, create new replica keys in each AWS Region where you plan to replicate Identity Center. To complete this step, follow the documentation in Create multi-Region replica keys.

Note: The replica key automatically inherits the same key policy as the primary customer-managed KMS key. However, future modifications to the key policy must be manually applied to the replica key in each Region. AWS KMS replica keys are independent resources; policy changes on the primary key do not propagate automatically.

Add an additional Region to Identity Center

Now that key replication is complete, you can add an additional Region to your Identity Center instance. For this post, use Frankfurt (eu-central-1). If you have a delegated admin account configured, we recommend completing remaining configurations in that account. We will perform this configuration using the console, but you can also use the IAM Identity Center API. For detailed instructions, see Add the Region in IAM Identity Center.

  1. Open the AWS Management Console.
  2. In the search bar, enter IAM Identity Center and choose the service.
  3. In the navigation pane, choose Settings.
  4. Choose Add Region.
    5. Figure 1: Management tab with encryption and Region information

    Figure 1: Management tab with encryption and Region information

  5. From the Region list on the following page, select Frankfurt (eu-central-1). Then, choose Add Region.

    6. The Region list shows Regions enabled by default where the customer-managed KMS key was replicated, making them available for you to choose.

    Figure 2: Choose an AWS Region to add

    Figure 2: Choose an AWS Region to add

  6. You’ll return to the Settings for Identity Center page, where you’ll see the new Region with a Replicating status. A blue banner indicates that Identity Center is replicating your workforce identities, configuration, and metadata to the new Region. After the initial setup (15–30 minutes, depending on the size of your Identity Center instance), future changes replicate within seconds.
    7. Figure 3: Initial replication to the newly added Region in progress

    Figure 3: Initial replication to the newly added Region in progress

  7. After replication completes, the Replication Status column changes to Replicated. Your Identity Center endpoints in the additional Region are now active.
    8. Figure 4: A console view after the initial replication is done

    Figure 4: A console view after the initial replication is done

  8. Users can now access AWS accounts through both AWS access portal URLs. You can view and copy the enabled portal URLs either from the Region list or by choosing View AWS access portal URLs.

You can view Security Assertions Markup Language (SAML) information, such as ACS URLs, about the primary and additional Regions by choosing View ACS URLs. In the next section you will use both, your AWS access portal URLs and ACS URLs to update your external IdP configuration.

Update your IdP configuration for the additional Region

You’ve successfully replicated your Identity Center instance to the Frankfurt (eu-central-1) Region. This means your workforce identities are now available in that additional Region and can use the new AWS access portal endpoint. Identity Center supports two authentication flows: one where users start from the AWS access portal or AWS managed application (service provider-initiated), and one where users start from their IdP portal (IdP-initiated). With service provider-initiated authentication, when users attempt to authenticate, Identity Center redirects them to your IdP authentication page, and after successful authentication, their authentication response is sent to the Regional SAML assertion consumer service (ACS) endpoint in Identity Center. The ACS endpoint in the additional Region uses a different URL than the primary Region, as shown in the following image.

Figure 5: Identity Center URLs

Figure 5: Identity Center URLs

Currently, your IdP only has information about your Identity Center in the primary Region. To successfully redirect users’ authentication responses to the additional Region, you must add the new Regional endpoint to the IdP configuration.

Update the Identity Center application in your IdP:

This update enables service provider-initiated authentication to succeed. In the Identity Center app within your external IdP, add the ACS URL for the additional Region so that the app contains both Regional ACS URLs. Keep the existing URL as the first one in the list, the IdP uses the first URL as the default redirect target for IdP-initated authentication. The additional ACS URL will be used by the IdP to send the authentication response when users sign in using service provider-initiated authentication flows.

As an example, follow the instructions to configure your Identity Center application in Okta:

  1. Log in to the Okta portal as an Admin.
  2. Expand the Applications drop-down in the left pane, then choose Applications
  3. Choose your Identity Center Application
  4. Select the Sign-on tab and choose Edit in the Settings windows.
  5. In the AWS SSO ACS URL1 box add the additional ACS URL
Figure 6 – Identity Center enterprise application configuration in Okta

Figure 6: Identity Center enterprise application configuration in Okta

Users can now access accounts starting from the Region-specific AWS access portal, in this case they need to remember two Region specific URLs, one for Frankfurt (eu-central-1) and one for N. Virginia (us-east-1). To accommodate these Region-specific portal URLs, we recommend creating a bookmark application in your IdP. While users can also bookmark the URLs directly in their browsers, providing a bookmark app makes the additional Region discoverable in the IdP portal without requiring each user to manually save a URL.

This bookmark app functions like a browser bookmark and contains only the URL to the AWS access portal in the additional Region. Users can access this bookmark app from their IdP portal to reach the Region-specific AWS access portal. You also must grant your users access to the bookmark app in the external IdP. In Okta, follow the instructions below:

  1. Log in to the Okta portal as an Admin.
  2. Expand the Applications drop-down in the left pane, then choose Applications.
  3. Choose Browse App Catalog
  4. Search for “Bookmark App”, select it from the list of results, and choose Add in the left pane.
  5. Choose an app name. For this blog post, the name can be “Identity Center – Frankfurt (eu-central-1)”
  6. In the URL box, paste the Frankfurt (eu-central-1) specific URL
  7. Choose Done. You will be redirected to the Bookmark application in the Assignments tab.
  8. Choose Assign and select the Groups/People that will have access to this application.

After completing this configuration, users will see two Identity Center applications in their IdP portal—one for the primary Region and another for the additional Region.
Figure 7 shows how this configuration appears in the Okta end user dashboard.

Figure 7: Okta end-user portal with two Region-specific tiles for Identity Center

Figure 7: Okta end-user portal with two Region-specific tiles for Identity Center

If you choose the newly created bookmark app, it will direct you to the AWS access portal in the additional Region.

Note: Identity Center supports IPv4-only endpoints, and dual-stack endpoints that support both IPv6 and IPv4. Depending on where your organization is in the process of IPv6 adoption, you will need to configure corresponding Assertion Consumer Service (ACS) URLs in your external IdP and used the corresponding AWS access portal URLs in your IdP bookmark application. For more information, see IPv6 support in Identity Center blog.

Test your multi-Region configuration

In the previous sections, you finished configuring the requirements for Identity Center multi-Region replication between the primary N. Virginia (us-east-1) and additional Frankfurt (eu-central-1) Regions. With this configuration complete, users with sufficient permissions can now enable supported AWS managed applications in either Region. Additionally, users can access their AWS accounts through the AWS access portal from either Region. To validate both capabilities, you will first test AWS account access from the additional Region and then configure a supported AWS managed application in that Region.

Accessing AWS accounts from the additional Region

Permission set assignment that exists in the primary Region of your Identity Center instance will be replicated to your additional Region. This means that, if there is a service disruption in Identity Center in the primary Region, you can switch to the additional Region to access your AWS accounts through the access portal or AWS CLI. To complete this section, your user in Identity Center needs existing access to an AWS account with permission sets. For more information see Manage AWS accounts with permission sets.

Access AWS accounts from the additional Region using the AWS access portal

  1. Open the IAM Identity Center console.
  2. In the navigation pane, choose Settings.
  3. Choose the Management tab.
  4. Choose View AWS access portal URLs.
  5. Choose additional Region URL, a new browser tab will open with the AWS access portal in Frankfurt (eu-central-1).
  6. Confirm you can see permission sets assigned to you.
  7. Choose a permission set, confirm that you can access your AWS account.

Access AWS accounts from the additional Region using the AWS CLI

AWS Command Line Interface (AWS CLI) connects to a specific Identity Center Region to authenticate users and obtain credentials. For customers using multi-Region replication, we recommend creating multiple Regional CLI profiles—one for your primary Region and another for each additional Region. Separate profiles allow you to quickly switch between Regions during a disruption without reconfiguring your CLI. Before completing this section, confirm that AWS CLI version 2.x or later is installed and that you have an existing AWS CLI configuration file.
To facilitate Region-specific access through the AWS CLI, create two CLI profiles using the following configuration:

  1. Open your AWS CLI configuration file at ~/.aws/config.
  2. Add the following two profiles configurations, one per additional Region. The example below shows a user in Virginia using N. Virginia (us-east-1) as their primary Identity Center Region with Frankfurt (eu-central-1) as a backup. Replace with your actual Identity Center instance ID and with your account number. To find your Identity Center instance ID, navigate to IAM Identity Center console, Settings, Instance ARN (the instance ID is the value that starts with ‘ssoins-‘)
  3. Save the file. 
    [profile ReadOnly]
sso_role_name=ReadOnly
sso_account=<account-Id>
sso_session=us-east-1

[sso-session us-east-1]
sso_region=us-east-1
sso_start_url=https://identitycenter.amazonaws.com/ssoins-<instance-Id>

[profile ReadOnly-additional]
sso_role_name=ReadOnly
sso_account=<account-Id>
sso_session=eu-central-1

[sso-session eu-central-1]
sso_region=eu-central-1
sso_start_url=https://identitycenter.amazonaws.com/ssoins-<instance-Id>

Once the profiles have been configured, you can authenticate to each regional Identity Center endpoint independently using the following commands.
1. Run aws sso login –profile ReadOnly to log in through your primary Region N. Virginia (us-east-1),
2. Run aws sso login –profile ReadOnly-additional to log in through your additional Region Frankfurt (eu-central-1)

Each command opens a browser window to the corresponding regional AWS access portal, where you complete the authentication flow. After a successful login, the AWS CLI uses the credentials obtained from that Region for subsequent API calls made with that profile.

Deploy AWS managed applications in the additional Region

To test application deployment in the additional Region, for this blog post you will configure AWS Deadline Cloud, a managed service for rendering and visual effects workloads. You can choose other AWS managed applications that support deployment in additional Identity Center Regions — see the AWS managed applications that you can use with IAM Identity Center table in the documentation. This table is regularly updated as additional applications become available.
To configure AWS Deadline Cloud, follow the steps:

  1. Navigate to the AWS Deadline Cloud console and switch to your additional Region—for this example, Frankfurt (eu-central-1).
  2. Choose Set up Deadline Cloud on the Get Started section and follow the configuration wizard until Step 2: Set up monitor.
  3. In the Set up monitor screen, enter a name (for example, Frankfurtmonitorapp), then expand the Additional monitor settings menu. Notice how the Identity Center instance in Frankfurt (eu-central-1) is automatically selected by the AWS DeadLine Cloud wizard. Choose Next.
  4. On Define farm details, under Groups and users, select the group that will have access to the application, verify you are a member of that group. Notice how you can automatically choose groups that were synced from your IdP into your Identity Center instance.
  5. For this demonstration, leave remaining configurations with their default values and complete the application setup by following the wizard. After the application deployment is complete, choose Go to dashboard.

The application is now configured to use Region-local Identity Center service APIs for user sign-in and access to workforce identities. The dashboard displays the option to manage users, and user assignment management for this application is performed through the Frankfurt (eu-central-1) Region.

Testing user access to your AWS managed application

You can test user access to AWS Deadline Cloud by choosing Monitor in the upper right-hand corner of the dashboard. This initiates the service provider authentication workflow, which redirects you to your IdP for authentication. Because your IdP now recognizes the Frankfurt (eu-central-1) ACS URL, it knows where to send the successful authentication response, and you are authorized to access the newly created application.

You can also access the application using the application provided endpoint or through your AWS access portal. The AWS access portal in each Region displays the applications assigned to the user independent of the Region they are configured.

What happens when you try to enable your application in a Region where Identity Center isn’t configured?

If Frankfurt (eu-central-1) hasn’t been added to your Identity Center instance, the application console will detect your organization instance in N. Virginia (us-east-1), and prompt you to enable Frankfurt (eu-central-1) first.

Figure 8: AWS Deadline cloud console wizard when Identity Center isn’t configured in the current Region

Figure 8: AWS Deadline cloud console wizard when Identity Center isn’t configured in the current Region

Note: Existing deployments of AWS managed applications that use cross-Region calls with Identity Center (for example, Amazon Q Business) continue to function normally. When deploying an AWS managed application that supports cross-Region calls, we recommend configuring it to use Identity Center in the same Region, provided the prerequisites are met. Otherwise, you can configure the application to use Identity Center from one of its enabled Regions. See the respective AWS application’s User Guide to learn if it supports cross-Region calls to Identity Center.

Optional: Automatic failover of domains for AWS access portal

Identity Center provides Regional endpoints for the AWS access portal when you enable multi-Region replication. You can access these Regional instances directly, or you can build a redirection system that intelligently routes users to the nearest available AWS access portal endpoint with failover capabilities.

For a serverless implementation of automatic failover, you can combine several AWS services:

  • Amazon Route 53: Manages DNS routing with health checks and geoproximity-based routing policies to redirect users to their nearest Regional endpoint.
  • Amazon Application Recovery Controller (ARC): Orchestrates failover logic and provides readiness checks to ensure smooth transitions between Regions during service disruptions.
  • Application Load Balancer (ALB): Performs simple HTTP redirects to the appropriate Regional AWS access portal endpoints based on routing decisions.

This setup redirects users to a healthy endpoint in another Region if the primary Region goes down. Geoproximity routing sends users to their nearest endpoint under normal conditions.

Administration and auditing tasks by Region

The primary Region is the central management hub for instance-level configurations, while additional Regions provide Region-local application management and access capabilities. Application management is always performed in the Region where the application was configured.

This table shows the availability of use cases between Regions. The primary Region maintains centralized control over identity and access management, while additional Regions focus onRegion-specific application management and providing resilient access to AWS accounts.

Task category

Primary Region

Additional Region

Workforce identity management

Full management of workforce identities and user provisioning

Read-only

User session revocation

Revoke user sessions

Revoke user sessions

Instance-level configuration

Configuration changes and settings

Read-only

User assignments to applications (Region-specific)

For applications in the primary Region

For applications in an additional Region

Trusted identity propagation (TIP)

Use TIP with applications in the same Region

Use TIP with applications in the same Region

Enable/disable application access

For applications in the primary Region

For applications in an additional Region

External IdP configuration

Manage connection and configuration with external IdPs

Read-only

Customer-managed applications

Deploy and configure SAML and OAuth2 applications

Deploy and configure SAML and OAuth2 applications

AWS account access

Access AWS accounts through a Region-specific AWS access portal

Access AWS accounts through Region-specific AWS access portal

Application management (Region-specific)

Manage applications configured in the primary Region

Manage applications configured in additional Regions

Account access permissions

Configure and manage permission sets and account assignments

Not available

Conclusion

In this post, you learned how to extend your access to AWS through IAM Identity Center across multiple AWS Regions using multi-Region replication. To replicate your Identity Center instance to additional Regions, you need a multi-Region KMS key, updated IdP configuration, and network access to the new regional endpoints.

With multi-Region replication in place, your users gain resilient, low-latency access to AWS accounts and AWS managed applications through Region-specific AWS access portals. If a disruption occurs in the primary Region, users can continue working using already provisioned permissions through any additional Region. For organizations looking to deploy AWS managed applications beyond Deadline Cloud in additional Regions, consult the AWS managed applications that integrate with IAM Identity Center table in the Identity Center User Guide to verify that the application supports both customer-managed KMS keys and deployment in additional Regions before proceeding.

To explore the full range of IAM Identity Center multi-Region capabilities, including quota management, visit the Using IAM Identity Center across multiple AWS Regions user guide.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Alex Milanovic

Alex Milanovic

Alex is a Senior Product Manager at AWS Identity, with over a decade of expertise in identity and access management and more than 25 years in the tech sector. His work centers on empowering organizations of all sizes, from large enterprises to small and medium-sized businesses, to effectively adopt and implement identity and access management cloud services.

Laura Reith

Laura Reith

Laura is an Identity Solutions Architect at AWS, where she thrives on helping customers overcome security and identity challenges. In her free time, she enjoys wreck diving and traveling around the world.

Upcoming Speaking Engagements

Post Syndicated from B. Schneier original https://www.schneier.com/blog/archives/2026/03/upcoming-speaking-engagements-54.html

This is a current list of where and when I am scheduled to speak:

The list is maintained on this page.

Седмицата (9–14 март)

Post Syndicated from Светла Енчева original https://www.toest.bg/sedmitsata-9-14-mart/

Седмицата (9–14 март)

В четвъртък Съдът на ЕС постанови, че идентичността на транс хората, сменили пола в личните си документи в страна членка, трябва да се признава и в България. Не че ще последва нещо – две европейски съдилища задължиха България да признава и еднополовите бракове, сключени в чужбина, а тя си прави оглушки. Защо този път да е различно? Европейското и международното право за нищо ги нямаме.

Като заговорих за международно право, ако се чудите как парламентът гласува (защото Пеевски така поръча) кабинетът да ратифицира противоречащия на международното право Борд за мир на Тръмп, докато САЩ бомбардира Иран, ще споделя – аз пък изобщо не съм учудена. Това е последният популистки акт от цяла поредица не по-малко безумни.

Разбрахте ли например, че който е на възраст от 14 до 16 години и има гадже, с което се целува и гушка – дори да не прави секс с него, – може да отнесе между 5 и 20 години затвор? И това, както се казва в рекламите, не е всичко. Детето ще влезе в „регистъра на педофилите“, всеки ще може да научи името и домашния му адрес и няма да може да работи с деца, когато порасне. Ако не вярвате – Катерина Василева от „Свободна Европа“ го е обяснила много добре. Който на 15 е нямал гадже, с което се е целувал, нека пръв хвърли камъка. Признавам, че не съм от тези праведници. И макар с първата ми любов да бяхме единодушни, че сме още малки за секс, пак щяхме да сме престъпници, ако бяхме тийнейджъри днес. Изобщо, тази популистка „борба с педофилията“ дотук постигна най-вече това, че ни превърна в нация „педофили“.

″Наказателен популизъм”. Сексът под 16 години вече ще е забранен. Какво означава това
Възрастта за съгласие да правиш секс става 16 вместо 14 години. Депутатите я вдигнаха, за да пазят децата. Но юристи казват, че това води до противоречия – на 15 може да си едновременно жертва и извършител на престъпление – дори да си правил доброволен секс с твой връстник.
Седмицата (9–14 март)Свободна ЕвропаКатерина Василева
Седмицата (9–14 март)

И понеже съм досадна като китайска капка, отново питам: какво стана с разследването срещу учителката в детска градина в Каблешково, обвинена в сексуално насилие срещу 4-годишно момиченце, която един кмет от ГЕРБ защитаваше толкова пламенно?

Може би си мислите, че тази поправка в Наказателния кодекс няма да се прилага спрямо деца. Само че това ще зависи не от закона, а от нечия добра воля. Навремето, когато еднократната доза наркотик стана престъпление, също се смяташе, че няма да вкарват 18-годишни младежи в затвора за половин цигара марихуана. Ама не стана така. Превръщането на всякакви сексуални активности между тийнейджъри под 16 години в престъпление може много успешно да се използва не само от родители с комплекса на Едип или Електра, а и за политически натиск – ако някой неудобен политик има дете в съответната възраст, много вероятно е то да има гадже. Или за репресии срещу определени етнически групи с призиви като „Всички непълнолетни родители – в затвора!“. И т.н.

На позорния стълб
Темата „педофилия“ е достатъчно токсична, за да накара политиците да изглеждат единодушни. Така без особени колебания парламентът направи част от „регистъра на педофилите“ публична. Но предпазва ли това децата, или просто превръща страха в удобен политически инструмент? От Светла Енчева.
Седмицата (9–14 март)ТоестСветла Енчева
Седмицата (9–14 март)

Кои парламентарни групи са приели това малоумие? Всички. Ако смятате, че това трябва да се промени – предстоят избори, може би е добра идея да поговорите с депутатите, за които смятате да пуснете бюлетина, че гръбнакът е важно нещо в политиката. А популизмът е бездънен. Вчера – затвор за влюбени тийнейджъри, днес – ратификация на т.нар. Борд за мир…

Колкото и организации като Борда за мир да си измисли Тръмп обаче и колкото и неща да кръсти на свое име, управлението му не мирише добре. Мирише на нечисти пари, и то милиарди, разбираме от новия брой на бюлетина „Гласовете на Америка“ на Йоанна Елми. Но и това може да се прикрива с аромата на популизма… докато престане да може.

Гласовете на Америка – брой 13
Между конфликтите на интереси, милиардите, наливани в политика, и познатите схеми, властта отново се оказва добра инвестиция. Какво става в САЩ година след началото на втория мандат на Тръмп – в новия брой на „Гласовете на Америка“ от Йоанна Елми.
Седмицата (9–14 март)ТоестЙоанна Елми
Седмицата (9–14 март)

Като говорим за популизъм, един от символите му в България през последните 20 години – Бойко Борисов, според Емилия Милчева ритуално се сбогува с величието си. С кафенце. В началото на политическата си кариера той е нещо средно между Тодор Живков и Рамбо, а в края ѝ – послушник на Пеевски, е тъжната констатация на Емилия. И в колкото и подкаста да участва, харизмата му е непоправимо изтъркана.

На прощаване Борисов пие кафе
Бойко Борисов обикаля инфлуенсърски канали, но вместо като политически офанзиви интервютата му звучат като равносметка. Между самохвалството, носталгията и заяждането с опонентите прозира усещането, че цикълът на ГЕРБ приключва и започва ерата „след Борисов“. Коментар на Емилия Милчева.
Седмицата (9–14 март)ТоестЕмилия Милчева
Седмицата (9–14 март)

Ако сте прочели всичко дотук, според Дарина Сарелска сте изчезващ вид. Както и аз, която пиша този бюлетин, а и самата Дарина. Причината е, че самата журналистика е на изчезване – не само в България, а в световен план. Защо? Признайте си колко пъти в последно време не сте отворили статия по тема, по която търсите информация, защото изкуственият интелект ви е смлял най-важното и ви го е представил директно в браузъра. Има и други причини за края на журналистиката, но нека не преразказвам текста – с надеждата, че ще го прочетете.

Краят на журналистиката
Журналистиката губи не само пари и трафик, а и необходимостта да я има. Алгоритми, нюзинфлуенсъри и политици, които вече говорят директно на публиката, променят правилата на играта. Въпросът вече e не дали медиите са в криза, а дали обществото изобщо още иска журналистика. От Дарина Сарелска.
Седмицата (9–14 март)ТоестДарина Сарелска
Седмицата (9–14 март)

И други журналисти в България се борят срещу перспективата да се превърнат в изчезващ вид. Мария Цънцарова, Люба Ризова, Весела Кисьова и Васил Христов обявиха новото си начинание – „Извън ефир“, както и кампания за набиране на средства, за да могат да предложат независима медия. Ние от екипа на „Тоест“ им стискаме палци да успеят.

Не всичко е толкова безрадостно. От статията на най-новия автор на „Тоест“ – дванайсетокласника Димитри Захов струи оптимизъм и дори патриотизъм. В нея се разказва за успехите на България на полето на анимационните филми и за супергерои, които говорят български с гласовете на Мария Бакалова и Юлиан Костов. Ако имате нужда от глътка свеж въздух насред всички вътрешнополитически и външнополитически кошмари, Димитри е на вашите услуги.

България на картата на… анимациите?
Дванайсетокласникът Димитри Захов дебютира в „Тоест“, за да ни разкаже де е България във вселената на анимационните филми. Той не само знае много по темата, ами е взел и интервю от известния актьор Юлиан Костов, който… Но хайде да не издаваме най-интересното още преди да сте прочели статията.
Седмицата (9–14 март)ТоестДимитри Захов
Седмицата (9–14 март)

Не е на изчезване и дейността на Павлина Върбанова – докато съществува правопис, ще имаме нужда от нейните понятни разяснения на заплетени езикови казуси. В новата си статия тя разсъждава как с думи се заграждат територии. Защо Близкият изток за едни е Среден за други? Защо някои държави и градове си сменят имената? Павлина търси отговор на тези въпроси, а и на други покрай тях.

Близки и далечни, диви и глобални…
Защо Близкият за нас изток е Среден за други? Още ли е див Дивият запад? Какви геополитически мотиви стоят зад именуването и преименуването на територии? Или пък става дума за ребрандиране с цел изчеткване на имиджа? Павлина Върбанова проследява как езикът реагира на тези прелюбопитни феномени.
Седмицата (9–14 март)ТоестПавлина Върбанова
Седмицата (9–14 март)

Нещо друго, което няма изгледи скоро да изчезне, поне докато го има човечеството, е архитектурата. Добра или лоша, тя е навсякъде около нас, за разлика от архитектурната критика, която е изчезващ вид още преди журналистиката. Анета Василева обаче упорито продължава да пише в тази област. Гледахте ли разговора на Владислав Севов с Анета в рубриката ни „Тоест разговаряме“? Ако не, а и ако сте любопитни да научите отговора на въпроса има ли бъдеще архитектурната професия, заповядайте:

Тоест разговаряме – епизод 8
Къде изчезна разговорът за архитектурата? И кой трябва да участва в него – архитектите, институциите, инвеститорите, гражданите? Или всички заедно? В този епизод на видеоразговорите ви срещаме с Анета Василева, архитектурна изследователка, преподавателка и авторка в „Тоест“.
Седмицата (9–14 март)ТоестВладислав Севов
Седмицата (9–14 март)

Слуховете за смъртта на „Зелените“ в Германия също се оказаха преувеличени. Във федералната провинция Баден-Вюртемберг те изненадващо спечелиха, макар и с едва половин процент пред Християндемократическата партия. Защото имаха правилния кандидат – Джем Йоздемир, син на турски гастарбайтери. Тази победа обаче не бива да успокоява „Зелените“.

Случаят Джем (Йоздемир). Защо „Зелените“ победиха в Баден-Вюртемберг
Победата на „Зелените“ изглежда като статистическа грешка – 0,5 пункта пред ХДС. Но е важна, защото зад този резултат стои човек. Джем Йоздемир – син на турски гастарбайтери, „шваба“, както сам се нарича, и попкултурна фигура – се оказа факторът, който преобърна изборите. Как – от Светла Енчева.
Седмицата (9–14 март)ТоестСветла Енчева
Седмицата (9–14 март)

За финал – този път наистина не ми хрумва друга препоръка, освен да правим всичко по силите си да убеждаваме партиите и кандидатите, за които смятаме да гласуваме, че популизмът все пак трябва да има някакви граници. И че ако продължават да се снишават и да приемат все по-малоумни закони, България не я чака нищо добро.

Разбира се, препоръчвам да подкрепите и „Тоест“, макар журналистиката да е на изчезване. Всъщност точно поради това.

Станете дарител

20 антикорупционни закона

Post Syndicated from Bozho original https://blog.bozho.net/blog/4570

Борбата с корупцията не е просто слоган, а конкретни действия. На предните избори имахме подробна антикорупционна програма. И макар и в опозиция, следвахме тази програма. Ето 20 антикорупционни законодтелни промени, които внесохме в рамките на този парламент:

1. Закон за здравното осигуряване – електронни уведомления към пациента за извършени здравни дейности, така че пациентите да контролират фиктивните дейности, чрез които се източва здравната каса (напр. болница казва на здравната каса, че сте в болница, а вие дори не знаете).

2. Наказателно-процесуален кодекс – ограничаване на държането на дела „на трупчета“, което е основен инструмент за натиск на задкулисно-завладяната прокуратура.

3. Закон за специалните разузнавателни средства – ограничаване на злоупотребите със СРС-та (напр. подслушване), тъй като нерядко вместо инструмент за доказване на престъпления, това се е превърнало в инструмент за събиране на компромати.

4. Закон за обществените поръчки – частни болници да правят търгове за лекарства, за да постигат по-добри цени, а не да възлагат на свързани фирми и така сами да определят цената, която здравната каса след това да има плаща.

5. Закон за управление на отпадъците – либерализация на режима за оползотворяване на отпадъци, което да доведе до намаляване на продутковите такси, които плащат всички, когато си купуват продукти, които оставят отпадък. Тези такси бяха вдигнати десетократно и това се отрази на цените, а причината беше, че едни мутри са превзели и МОСВ, и оползотворяващите организации.

6. Закон за здравето – ограничаване на фалшивите ТЕЛК-ове чрез система за автоматизирана оценка на риска. Има 800 хиляди души с ТЕЛК, което е огромен разход за бюджета. Част от тези хора всъщност нямат никакво сериозно заболяване, а си плащат за ТЕЛК, за да ползват привилегии – паркомясто, намалени такси и др.

7. Закон за публичните предприятия – плащанията на големите и средните публични предприятия (държавни и общински) да бъдат публикувани, както направихме с държавната администрация – всяко плащане е публично, тъй като отворихме данните на системата СЕБРА. Прозрачността е ключов инструмент за борба на корупцията.

8. Закон за движението по пътищата – отпадане на стикерите от предното стъкло. Това е корупция записана в закона и трябва да бъде премахната.

9. Закон за съдебната власт – разширяване на кръга от имащите право да номинират членове на Висшия съдебен съвет. Виждаме, че много често не е важно само какво пише в закона, а кой го прилага. Затова във Висшия съдебен съвет трябва да има хора с добра репутация и професионален опит, номинирани от университети, адвокатура и др, а не само от партиите.

10. Наказателно-процесуален кодекс – ограничаване на злоупотребите със следствената тайна. Когато Сметната палата или АДФИ открият корупция и предадат информацията на прокуратурата, тази информация потъва под булото на следствената тайна и прокуратурата я смакчва. Така стана с делото за корупцията в „Монтажи“, откъдето се източиха милиони. Предлагаме пуликуване на докладите на Сметна палата и АДФИ и много други промени, с които прокуратурата да не прикрива корупция.

11. Закон за обществените поръчки – предварително обявяване на критерии за отстраняване. В момента някои възложители правят следния „номер“ – обявяват поръчката на „най-ниска цена“ и после отстраняват всички участници с най-ниски цени по напълно изсмукани от пръстите критерии, за които са намерили да се заядат, за да спечели „който трябва“. Това трябва да спре.

12. Закон за ветеринарномедицинската дейност – публикуване на данни в реално време за регистрирани животни в системата на БАБХ. Това ще ограничи използването на фиктивни животни, които се появяват и изчезват от системата. А това пък води до ограничава на източването на субсидии.

13. Закон за търговския регистър и регистъра на ЮЛНЦ – разширяване на обхвата на отворените данни от регистъра, вкл. включване на данни за акционерите в акционерни дружества. Това дава на разследващи журналисти много повече възможности за откриване на връзки, които предполагат корупция. Напр. „брат на шеф на агенция и акционер в изпълнител на обществена поръчка.“

14. Закон за съдебната власт – обжалване на кадрови въпроси пред смесени съдебни съставки между двете върховни съдилища (ВАС и ВКС). В момента се обжалват само във ВАС, а там Чолаков гарантираше на Пеевски как ще приключат делата, което позволява пълно кадрово овладяване на съдебната система. Добавянето на ВКС ще въведе гаранции за обективно произнасяне.

15. Закон за мерките срещу изпирането на пари – въвеждане на задължения за банките за прилагане на санкции на партньорски държави (напр. санкциите по закона Магнитски). В момента санкционирани лица за корупция имат банкови сметки, а това е риск за финансовата система, предвид глобалния обхват на закона Магнитски.

16. Наказателно-процесуален кодекс – дигитализация на досъдебното производство, така че делата да не са на хартия в папки, да не се губят, да не се преправят тефтерчета, да не се бавят между разследващ орган и прокурор, докато не се падне удобен съдебен състав и др. Всяка дигитализация ограничава корупционни практики.

17. Закон за държавния бюджет – ясна поредност на плащанията по общинската програма. В редовното правителство плащанията бяха приоритизирани за хора, които са се снимали под герба на Пеевски, вкл. бяха изнудвани с това, че няма да им бъдат отпуснати пари за общинските проекти, докато не „припознаят новото начало“. С нашите предложения такъв субективизъм отпада, тъй като плащанията стават дължими по реда на получаване (и отстраняване на нередовности) на документацията.

18. Закон за превенция и противодействие на корупцията – на мястото на закритата КПК да бъде създадена комисия за превенция на корупцията и конфликта на интереси, която да се занимава с превенция – напр. да проверява обществени поръчки за дискриминационни условия още преди да има сключен договор и корупцията да се случи; да проверява предложения на депутати между първо и второ четене за „лобистки поправки“ и др. КПК беше бухалка, която се ползваше за натиск и увеличаване на корупционния риск – трябва институция, която да го ограничава.

19. Закон за чужденците в Република България – въвеждане на електронна система за разрешения за пребиваване със случайно разпределение, за да се ограничи корупцията в дирекция „Миграция“, където едни преписки „на правилни хора“ се движат бързо и без бележки, а други чакат с месеци.

20. Закон за здравното осигуряване – отворени данни за плащанията от НЗОК – когато касата плаща лекарства, медицински издели и дейности, тя има данните колко, на кого, какво е платено. Тези данни трябва да са публични, за да могат гражданите и разследващите журналисти да търсят аномалии – напр. защо на една болница е платено 3 пъти повече за едно лекарство или медицинско изделие от друга.

Корупцията, за съжаление, е навсякъде. Тя се ползва както за източване на обществени средства, така и за изкриваяване на политическата система чрез компромати и изнудване. Корупцията се бори трудно, особено когато прокуратурата е основен съучастник.

Затова предлагаме всички мерки по-горе, както и още много, много такива, залегнали в антикорупционната ни програма. Чрез дигитализация, прозрачност, правила, затваряне на „вратички“ и институционални гаранции, може корупцията стане твърде рискована и дори невъзможна за извършителите. Ще опитаме да приложим тези мерки в следващия парламент. За тях обаче трябва мнозинство, а за да бъдат ефективно приложени – изпълнителна власт.

Материалът 20 антикорупционни закона е публикуван за пръв път на БЛОГодаря.

The collective thoughts of the interwebz