Post Syndicated from digiblur DIY original https://www.youtube.com/watch?v=4uUDIN4uNVk
ACMER P2 33W Laser: Amazing Results… BUT Ventilation Is NOT Optional
Post Syndicated from BeardedTinker original https://www.youtube.com/watch?v=5iWFMUiQ84U
TP-Link TX201 2.5GbE PCIe Adapter Review
Post Syndicated from Rohit Kumar original https://www.servethehome.com/tp-link-tx201-2-5gbe-adapter-realtek-rtl8125/
We review the TP-Link TX201, a low-power NIC that uses a Realtek controller to add 2.5GbE to systems with free PCIe x1 ports
The post TP-Link TX201 2.5GbE PCIe Adapter Review appeared first on ServeTheHome.
Comic for 2026.01.18 – Partner
Post Syndicated from Explosm.net original https://explosm.net/comics/partner
New Cyanide and Happiness Comic
65 Essential Children’s Books
Post Syndicated from The Atlantic original https://www.youtube.com/shorts/FFDoc5mLHno
Deja View Camwear: Odd 23-Year-Old Camera Glasses
Post Syndicated from LGR original https://www.youtube.com/watch?v=vCfvFQH_1YA
Mancy
Post Syndicated from Oglaf! -- Comics. Often dirty. original https://www.oglaf.com/mancy/
Four stable kernels for the weekend
Seagate Shipping 32TB HAMR Hard Drives for Server, NAS, & Surveillance Markets
Post Syndicated from Ryan Smith original https://www.servethehome.com/seagate-shipping-32tb-hamr-hard-drives-for-server-nas-surveillance-markets/
Seagate has announced this week that it has begun shipping 32TB versions of its high-capacity, high-end hard drives. The second wave of hard drives based on Seagate’s heat-assisted magnetic recording (HAMR) technology, the 32TB drives mark the first capacity bump for Seagate’s top-capacity drives since Seagate brought HAMR-based drives to the retail market last year. […]
The post Seagate Shipping 32TB HAMR Hard Drives for Server, NAS, & Surveillance Markets appeared first on ServeTheHome.
Sophie Gilbert on the persistence of misogyny on tech platforms
Post Syndicated from The Atlantic original https://www.youtube.com/shorts/jB2P2ACCpTg
Нов договор с Майкрософт или търсене на алтернативи?
Post Syndicated from Bozho original https://blog.bozho.net/blog/4561
Предстои нов договор с Майкрософт за държавната администрация. На фона на централните политически събития и многото комуникационен шум, на заден план остана решението на Министерския съвет да възложи на министъра на електронното управление да проведе обществена поръчка за продукти на Майкрософт.
Преди да отворя темата за офис пакета, трябва да уточня две неща: 1) държавната администрация ползва много продукти на Microsoft, чието лицензиране и поддръжка трябва да уреди – Windows Server, SQL Server и др. Това не е офис пакета и там дори да имаме технологични спорове за Windows vs Linux и за най-удачния избор за системи за бази данни, безпорна е нуждата от поддръжка. и 2) Microsoft е компания с добра репутация и големи и компетентни партньорски мрежи, което осигурява достатъчни гаранции за администрацията, че няма да бъде оставена да се оправя сама (което тя не може).
След тези уточнения, да минем на темата с офис пакета. Microsoft от много години предлага Office365 – облачен офис, при който Word, Excel и PowerPoint продължават да работят локално, но имат и функционалности за споделяне и колаборация, които пък изискват облачна интеграция. Предлага и централизирано управление на имейл. В частния сектор съм бил клиент на Office365, и той спестява много главоболия и налага много добри практики, вкл. във връзка с киберсигурността. Имам и негативен опит с поддръжката в Индия, която един месец не можа да разбере какво ги питам и накрая си призна, че имат бъг, но нетният резултат е безспорно позитивен.
Но тук идва проблемът, с който се сблъсках като министър – Майкрософт изисква всички потребителски акаунти да бъдат в облачната активна директория (AzureAD/Entra). Това означава цялата държавна администрация (десетки хиляди служители) да бъдат управлявани в облака на Майкрософт. Друг проблем са данните – Microsoft не предлагаше на правителствата възможността да контролират изцяло ключовете за криптиране на данните, което значеше, че Microsoft на теория има достъп до всички данни.
През 2022 г. като министър, повдигнах тези въпроси като проблем за България, защото от гледна точка на националната сигурност и суверенитета, е дългосрочен риск да отдадем толкова много контрол на компания от трета страна. Оттогава Майкрософт въведоха повече възможности за криптиране на данните от правителства – през 2025 г. въведоха поддръжка за хибридни среди с държавна инфраструктура, което е стъпка в правилната посока.
На този фон, обаче, идва проблемът е международния наказателен съд в Хага. След като Тръмп санкционира съда в хага, достъпът до имейла (в Office365) на главния прокурор към съда е бил спрян. Майкрософт първо не коментира, а после отрича да са правили нещо нередно. Но каквато и да е реалната ситуация, администрацията на САЩ разполага с инструменти да наложи определени действия на американските технологични компании.
Друга история от 2022 г. – един от големите облачни доставчици (hyperscaler-и) разглеждаше възможност за партньорство с българското правителство. Бидейки наясно с вътрешния капацитет за поддържане на облачна инфраструктура, бях много отворен към хибридни модели, в които ползваме и дори насърчаваме инвестиции на hyperscaler-и в страната, съвместно с наша инфраструктура. За съжаление времето беше твърде кратко за се развие такова партньорство, но в рамките на една среща казах, че е изключително важно да има възможност за безпроблемна мгирация извън облака, поне на ниво виртуална машина, за да няма т.нар. vendor lock-in. Те ме увериха, че няма никакъв проблем с миграцията на виртуални машини, без да знаят, че предната вечер бях мигрирал такава, във връзка със спешното създаване на български сайт за украински бежанци и се беше оказало, че изобщо не е безпроблмно и има доста скрити пречки.
В този контекст, дългосрочното обвързване на държавата с външен доставчик на такива централни услуги, без възможност и подготовка за миграция в рамките на часове, е доста рисково. Както от гледна точка на достъпа до данните, така и от гледна точка на наличността на услулгата – ако някой може да спре от днес за утре достъпа до ключова услуга по политически причини, това е проблем.
Германия отдавна е осъзнала този проблем, поради което е създала Центъра за цифров суверенитет (ZenDIS), който разработва продукти, които немската администрация ползва и чрез които не зависи от външни доставчици. След гореописания инцидент, Международният наказателен съд в Хага мигрира от Office365 към openDesk на ZenDIS, който е изцяло с отворен код.
Нека горното да не се чете като обвинение към американските компании – не че нямам технологични критики към тях, но те предоставят добри продукти, които за съжаление никоя европейска компания не е успяла да развие и наложи в такава степен.
Но от гледна точка на дългосрочните рискове и на новата ситуация, в която партньорството между САЩ и Европа е поставено под въпрос от Белия дом, следва да оценяваме внимателно и технологичните си решения.
В решението на Министерския съвет е записано „или еквивалентни“, което позволява на МЕУ да разграничи поддръжката на съществуващи сървърни продукти от офис пакета и да помисли за отворени алтернативи, които да гарантират цифров суверенитет.
Материалът Нов договор с Майкрософт или търсене на алтернативи? е публикуван за пръв път на БЛОГодаря.
Седмицата (12–17 януари)
Post Syndicated from Йовко Ламбрев original https://www.toest.bg/sedmitsata-12-17-yanuari/

Едва преполовихме януари, а толкова много неща вече успяха да се случат с дата от 2026 година. Ако вече се чувствате така, сякаш сте преживели цял месец (или даже няколко месеца), това не е само ваше субективно усещане. Когато събитията връхлитат с такава честота, настоящето сякаш се компресира до миг, в който няма време за осмисляне на една новина, преди тя да бъде пометена от следващата.
И не е само времето. Дистанциите окончателно губят значението си, а икономическите и политическите трусове в различни точки на планетата резонират мигновено и едновременно в нашия дневен ред, сякаш и светът внезапно се е свил. Иран, Венецуела, Украйна, Газа, Минеаполис, Гренландия… са не твърде по-далеч от покрайнините на градовете ни и съвсем не в периферията на мислите ни.
В „Тоест“ обаче никога не се напъваме да вместим повече история в единица време, защото отдавна знаем, че това води не до по-богат опит, а до колективно задъхване и усещане, че бягаме на място, опитвайки се да догоним опашката си. Затова разглобяваме свръхнаситеното с информация ежедневие, търсейки тези парченца, които носят смисъл и имат значение за бъдещето.
А онова, което има най-голямо значение за бъдещето на всички ни тук, в България, е да разглобим и унищожим веднъж завинаги добре смазаната, но смазваща развитието на страната ни машина за избори на управляващите. Това може да стане само с невиждано и нечувано масово гласуване на предстоящите предсрочни избори. Защото иначе онези никога няма да допуснат машинно гласуване, никога няма да изпуснат контрола върху броенето, а тяхното си МВР ще продължи да си затваря очите пред изборните безобразия и купувачите на гласове. Повече по темата четете в седмичния анализ на Емилия Милчева „В броячите е силата. Не, в гражданите“.
И ето! Доживяхме и новогодишното приветствие на Е.Т. в комплект със саркастичния ѝ коментар за събитията от седмицата. Видеото съдържа нездравословни дози груба действителност. Гледайте го на своя отговорност.
Толерантни ли сме един към друг? Как мислите? Да? Не? Зависи? Адски сме толерантни!, зашеметява ни още със заглавието на статията си тази седмица Светла Енчева. За да ни довърши с анализа си на последните резултати (за 2025 г.) от ежегодното национално представително изследване на обществените нагласи спрямо ЛГБТИ хората. Е, има и някои добри новини и тенденции. Аз пък си мисля, че ако темата някой ден излезе от режима на пропагандно-политическата експлоатация, обществото ни трябва да успее да я обговори и надрасне спокойно. Дано се случи по-скоро.
С политическия си анализ тази седмица Искрен Иванов се опитва рационално да обясни последните действия на администрацията на Тръмп, които ни изглеждат откровено безумни. И безпрецедентни само на фона на днешния контекст, но не и в рамките на историческите натрупвания, които често погрешно допускаме, че са останали безвъзвратно в миналото, а може би не са. Или продължават да имат своето влияние и днес. Може да прочетете повече в статията му „Да владееш или да не владееш? Как Западът се върна към началото на XX век“.
За Тръмп и САЩ няма как да не стане дума и в новия епизод на видеопоредицата ни „Тоест разговаряме“, който ще излъчим на живо днес, 17 януари, от 16:00 часа в нашия YouTube Live. Защото събеседник на Владислав Севов ще бъде Йоанна Елми, авторка в „Тоест“ от началото на 2019 г. и водеща на рубриката „Гласовете на Америка“. В анкетата на епизода може да зададете предварителен въпрос на Йоанна и да довършите изречението „Американската мечта е…“.
Дори литературната ни колонка „На второ четене“ е уплътнена със свръхбагажа на новото трескаво ежедневие. И за съжаление – напоена с кръв. С неизбежните паралели между там и тук, тях и нас. Стефан Иванов е виновен за това – и Остап Сливински с неговия „Речник на войната“. Защото според Стефан
езикът е последното бойно поле. След като градовете са паднали, след като институциите са рухнали, след като идентичностите са разбити, остава още въпросът как ще говорим за това… Ще говорим внимателно, болезнено и честно. Ще говорим така, сякаш думите тежат. Защото тежат.
И още паралели… Този път със Сърбия, за която ни разказва италианката Джорджа Спадони в няколко статии от първо лице. Тази седмица публикувахме най-новия материал от поредицата ѝ, който е озаглавен „Какво става в Сърбия? Непредвидимото бъдеще“. Текстът завършва с констатацията, че за добро или зло друго бъдеще няма – с това разполагаме. Но го има очевидния намек, че все пак от нас зависи какво ще бъде то.
Струва ми се, че сполучливо допълнение към статията на Джорджа би било припомнянето на един кратък документален филм на вече над 20 години. Той е за един исторически импулс, изпълнен с много човешки, обикновени мечти, който сега можеше да се е превърнал в по-различно настояще, ако повече хора бяха повярвали в него и в собствените си сили за промяна.
„Няма народ, който да е направил погрешен политически избор и да не е платил цената за това“, ще чуете да казва Зоран Джинджич в този филм. Затова стига вече грешни избори!
A Romance That Actually Takes Sex Seriously
Post Syndicated from The Atlantic original https://www.youtube.com/shorts/KC8taGfwjuM
Implementing data governance on AWS: Automation, tagging, and lifecycle strategy – Part 2
Post Syndicated from Omar Ahmed original https://aws.amazon.com/blogs/security/implementing-data-governance-on-aws-automation-tagging-and-lifecycle-strategy-part-2/
In Part 1, we explored the foundational strategy, including data classification frameworks and tagging approaches. In this post, we examine the technical implementation approach and key architectural patterns for building a governance framework.
We explore governance controls across four implementation areas, building from foundational monitoring to advanced automation. Each area builds on the previous one, so you can implement incrementally and validate as you go:
- Monitoring foundation: Begin by establishing your monitoring baseline. Set up AWS Config rules to track tag compliance across your resources, then configure Amazon CloudWatch dashboards to provide real-time visibility into your governance posture. By using this foundation, you can understand your current state before implementing enforcement controls.
- Preventive controls: Build proactive enforcement by deploying AWS Lambda functions that validate tags at resource creation time. Implement Amazon EventBridge rules to trigger real-time enforcement actions and configure service control policies (SCPs) to establish organization-wide guardrails that prevent non-compliant resource deployment.
- Automated remediation: Reduce manual intervention by setting up AWS Systems Manager Automation Documents that respond to compliance violations. Configure automated responses that correct common issues like missing tags or improper encryption and implement classification-based security controls that automatically apply appropriate protections based on data sensitivity.
- Advanced features: Extend your governance framework with sophisticated capabilities. Deploy data sovereignty controls to help ensure regulatory compliance across AWS Regions, implement intelligent lifecycle management to optimize costs while maintaining compliance, and establish comprehensive monitoring and reporting systems that provide stakeholders with clear visibility into your governance effectiveness.
Prerequisites
Before beginning implementation, ensure you have AWS Command Line Interface (AWS CLI) installed and configured with appropriate credentials for your target accounts. Set AWS Identity and Access Managment (IAM) permissions so that you can create roles, Lambda functions, and AWS Config rules. Finally, basic familiarity with AWS CloudFormation or Terraform will be helpful, because we’ll use CloudFormation throughout our examples.
Tag governance controls
Implementing tag governance requires multiple layers of controls working together across AWS services. These controls range from preventive measures that validate resources at creation to detective controls that monitor existing resources. This section describes each control type, starting with preventive controls that act as first line of defense.
Preventive controls
Preventive controls help ensure resources are properly tagged at creation time. By implementing Lambda functions triggered by AWS CloudTrail events, you can validate tags before resources are created, preventing non-compliant resources from being deployed:
For complete, production-ready implementation, see Implementing Tag Policies with AWS Organizations and EventBridge event patterns for resource monitoring.
Organization-wide policy enforcement
AWS Organizations tag policies provide a foundation for consistent tagging across your organization. These policies define standard tag formats and values, helping to ensure consistency across accounts:
Detailed implementation guidance: Getting started with tag policies & Best practices for using tag policies
Tag-based access control
Tag-based access control gives you detailed permissions using attribute-based access control (ABAC). By using this approach, you can define permissions based on resource attributes rather than creating individual IAM policies for each use case:
Multi-account governance strategy
While implementing tag governance within a single account is straightforward, most organizations operate in a multi-account environment. Implementing consistent governance across your organization requires additional controls:
For more information, see implementation guidance for SCPs.
Integration with on-premises governance frameworks
Many organizations maintain existing governance frameworks for their on-premises infrastructure. Extending these frameworks to AWS requires careful integration and applicability analysis. The following example shows how to use AWS Service Catalog to create a portfolio of AWS resources that align with your on-premises governance standards.
Automating security controls based on classification
After data is classified, use these classifications to automate security controls and use AWS Config to track and validate that resources are properly tagged through defined rules that assess your AWS resource configurations, including a built-in required-tags rule. For non-compliant resources, you can use Systems Manager to automate the remediation process.
With proper tagging in place, you can implement automated security controls using EventBridge and Lambda. By using this combination, you can create a cost-effective and scalable infrastructure for enforcing security policies based on data classification. For example, when a resource is tagged as high impact, you can use EventBridge to trigger a Lambda function to enable required security measures.
This example automation applies security controls consistently, reducing human error and maintaining compliance. Code-based controls ensure policies match your data classification.
Implementation resources:
- Remediating Noncompliant Resources with AWS Config
- AWS Systems Manager – Creating your own runbooks
- AWS Encryption SDK Developer Guide
- Lambda error handling patterns
- EventBridge event patterns
Data sovereignty and residency
Data sovereignty and residency requirements help you comply with regulations like GDPR. Such controls can be implemented to restrict data storage and processing to specific AWS Regions:
Note: This example uses eu-west-1 and eu-central-1 because these Regions are commonly used for GDPR compliance, providing data residency within the European Union. Adjust these Regions based on your specific regulatory requirements and business needs. For more information, see Meeting data residency requirements on AWS and Controls that enhance data residence protection.
Disaster recovery integration with governance controls
While organizations often focus on system availability and data recovery, maintaining governance controls during disaster recovery (DR) scenarios is important for compliance and security. To implement effective governance in your DR strategy, start by using AWS Config rules to check that DR resources maintain the same governance standards as your primary environment:
For your most critical data (classified as Level 1 in part 1 of this post), implement cross-Region replication while maintaining strict governance controls. This helps ensure that sensitive data remains protected even during failover scenarios:
Automated compliance monitoring
By combining AWS Config for resource compliance, CloudWatch for metrics and alerting, and Amazon Macie for sensitive data discovery, you can create a robust compliance monitoring framework that automatically detects and responds to compliance issues:
Figure 1: Compliance monitoring architecture
This architecture (shown in Figure 1) demonstrates how AWS services work together to provide compliance monitoring:
- AWS Config, CloudTrail, and Macie monitor AWS resources
- CloudWatch aggregates monitoring data
- Alerts and dashboards provide real-time visibility
The following CloudFormation template implements these controls:
These controls provide real-time visibility into your security posture, automate responses to potential security events, and use Macie for sensitive data discovery and classification. For a complete monitoring setup, review List of AWS Config Managed Rules and Using Amazon CloudWatch dashboards.
Using AWS data lakes for governance
Modern data governance strategies often use data lakes to provide centralized control and visibility. AWS provides a comprehensive solution through the Modern Data Architecture Accelerator (MDAA), which you can use to help you rapidly deploy and manage data platform architectures with built-in security and governance controls. Figure 2 shows an MDAA reference architecture.
Figure 2: MDAA reference architecture
For detailed implementation guidance and source code, see Accelerate the Deployment of Secure and Compliant Modern Data Architectures for Advanced Analytics and AI.
Access patterns and data discovery
Understanding and managing access patterns is important for effective governance. Use CloudTrail and Amazon Athena to analyze access patterns:
This query helps identify frequently accessed data and unusual patterns in access behavior. These insights help you to:
- Optimize storage tiers based on access frequency
- Refine DR strategies for frequently accessed data
- Identify of potential security risks through unusual access patterns
- Fine-tune data lifecycle policies based on usage patterns
For sensitive data discovery, consider integrating Macie to automatically identify and protect PII across your data estate.
Machine learning model governance with SageMaker
As organizations advance in their data governance journey, many are deploying machine learning models in production, necessitating governance frameworks that extend to machine learning (ML) operations. Amazon SageMaker offers advanced tools that you can use to maintain governance over ML assets without impeding innovation.
SageMaker governance tools work together to provide comprehensive ML oversight:
- Role Manager provides fine-grained access control for ML roles
- Model Cards centralize documentation and lineage information
- Model Dashboard offers organization-wide visibility into deployed models
- Model Monitor automates drift detection and quality control
The following example configures SageMaker governance controls:
This example demonstrates two essential governance controls: role-based access management for secure service interactions and automated hourly monitoring for ongoing model oversight. While these technical implementations are important, remember that successful ML governance requires integration with your broader data governance framework, helping to ensure consistent controls and visibility across your entire data and analytics ecosystem. For more information, see Model governance to manage permissions and track model performance.
Cost optimization through automated lifecycle management
Effective data governance isn’t just about security—it’s also about managing cost efficiently. Implement intelligent data lifecycle management based on classification and usage patterns, as shown in Figure 3:
Figure 3: Tag-based lifecycle management in Amazon S3
Figure 3 illustrates how tags drive automated lifecycle management:
- New data enters Amazon Simple Storage Service (Amazon S3) with the tag
DataClassification: L2 - Based on classification, the data starts in
Standard/INTELLIGENT_TIERING - After 90 days, the data transitions to Amazon S3 Glacier storage for cost-effective archival
- The
RetentionPeriodtag (84 months) determines final expiration
Here’s the implementation of the preceding lifecycle rules:
S3 Lifecycle automatically optimizes storage costs while maintaining compliance with retention requirements. For example, data initially stored in Amazon S3 Intelligent-Tiering automatically moves to Glacier after 90 days, significantly reducing storage costs while helping to ensure data remains available when needed. For more information, seeManaging the lifecycle of objects and Managing storage costs with Amazon S3 Intelligent-Tiering.
Conclusion
Successfully implementing data governance on AWS requires both a structured approach and adherence to key best practices. As you progress through your implementation journey, keep these fundamental principles in mind:
- Start with a focused scope and gradually expand. Begin with a pilot project that addresses high-impact, low-complexity use cases. By using this approach, you can demonstrate quick wins while building experience and confidence in your governance framework.
- Make automation your foundation. Apply AWS services such as Amazon EventBridge for event-driven responses, implement automated remediation for common issues, and create self-service capabilities that balance efficiency with compliance. This automation-first approach helps ensure scalability and consistency in your governance framework.
- Maintain continuous visibility and improvement. Regular monitoring, compliance checks, and framework updates are essential for long-term success. Use feedback from your operations team to refine policies and adjust controls as your organization’s needs evolve.
Common challenges to be aware of:
- Initial resistance to change from teams used to manual processes
- Complexity in handling legacy systems and data
- Balancing security controls with operational efficiency
- Maintaining consistent governance across multiple AWS accounts and regions
For more information, implementation support, and guidance, see:
- AWS Security Blog
- AWS Architecture Center
- AWS Compliance Resources
- Amazon Macie User Guide
- AWS Organizations Best Practices
By following this approach and remaining mindful of potential challenges, you can build a robust, scalable data governance framework that grows with your organization while maintaining security, compliance, and efficient data operations.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Implementing data governance on AWS: Automation, tagging, and lifecycle strategy – Part 1
Post Syndicated from Omar Ahmed original https://aws.amazon.com/blogs/security/implementing-data-governance-on-aws-automation-tagging-and-lifecycle-strategy-part-1/
Generative AI and machine learning workloads create massive amounts of data. Organizations need data governance to manage this growth and stay compliant. While data governance isn’t a new concept, recent studies highlight a concerning gap: a Gartner study of 300 IT executives revealed that only 60% of organizations have implemented a data governance strategy, with 40% still in planning stages or uncertain where to begin. Furthermore, a 2024 MIT CDOIQ survey of 250 chief data officers (CDOs) found that only 45% identify data governance as a top priority.
Although most businesses recognize the importance of data governance strategies, regular evaluation is important to ensure these strategies evolve with changing business needs, industry requirements, and emerging technologies. In this post, we show you a practical, automation-first approach to implementing data governance on Amazon Web Services (AWS) through a strategic and architectural guide—whether you’re starting at the beginning or improving an existing framework.
In this two-part series, we explore how to build a data governance framework on AWS that’s both practical and scalable. Our approach aligns with what AWS has identified as the core benefits of data governance:
- Classify data consistently and automate controls to improve quality
- Give teams secure access to the data they need
- Monitor compliance automatically and catch issues early
In this post, we cover strategy, classification framework, and tagging governance—the foundation you need to get started. If you don’t already have a governance strategy, we provide a high-level overview of AWS tools and services to help you get started. If you have a data governance strategy, the information in this post can assist you in evaluating its effectiveness and understanding how data governance is evolving with new technologies.
In Part 2, we explore the technical architecture and implementation patterns with conceptual code examples, and throughout both parts, you’ll find links to production-ready AWS resources for detailed implementation.
Prerequisites
Before implementing data governance on AWS, you need the right AWS setup and buy-in from your teams.
Technical foundation
Start with a well-structured AWS Organizations setup for centralized management. Make sure AWS CloudTrail and AWS Config are enabled across accounts—you’ll need these for monitoring and auditing. Your AWS Identity and Access Management (IAM) framework should already define roles and permissions clearly.
Beyond these services, you’ll use several AWS tools for automation and enforcement. The AWS service quick reference table that follows lists everything used throughout this guide.
Organizational readiness
Successful implementation of data governance requires clear organizational alignment and preparation across multiple dimensions.
- Define roles and responsibilities. Data owners classify data and approve access requests. Your platform team handles AWS infrastructure and builds automation, while security teams set controls and monitor compliance. Application teams then implement these standards in their daily workflows.
- Document your compliance requirements. List the regulations you must follow—GDPR, PCI-DSS, SOX, HIPAA, or others. Create a data classification framework that aligns with your business risk. Document your tagging standards and naming conventions so everyone follows the same approach.
- Plan for change management. Get executive support from leaders who understand why governance matters. Start with pilot projects to demonstrate value before rolling out organization-wide. Provide role-based training and maintain up-to-date governance playbooks. Establish feedback mechanisms so teams can report issues and suggest improvements.
Key performance indicators (KPIs) to monitor
To measure the effectiveness of your data governance implementation, track the following essential metrics and their target objectives.
- Resource tagging compliance: Aim for 95%, measured through AWS Config rules with weekly monitoring, focusing on critical resources and sensitive data classifications.
- Mean time to respond to compliance issues: Target less than 24 hours for critical issues. Tracked using CloudWatch metrics with automated alerting for high-priority non-compliance events
- Reduction in manual governance tasks: Target reduction of 40% in the first year. Measured through automated workflow adoption and remediation success rates.
- Storage cost optimization based on data classification: Target 15–20% reduction through intelligent tiering and lifecycle policies, monitored monthly by classification level.
With these technical and organizational foundations in place, you’re ready to implement a sustainable data governance framework.
AWS services used in this guide – Quick reference
This implementation uses the following AWS services. Some are prerequisites, while others are introduced throughout the guide.
|
Category |
Services |
Description |
|
Foundation |
Multi-account management structure that enables centralized policy enforcement and governance across your entire AWS environment. |
|
|
|
Controls who can access what resources through roles, policies, and permissions—the foundation of your security model. |
|
|
Monitoring and auditing |
Records every API call made in your AWS accounts, creating a complete audit trail of who did what, when, and from where. |
|
|
|
Continuously monitors resource configurations and evaluates them against rules you define (such as requiring that all S3 buckets much be encrypted). When it finds resources that don’t meet your rules, it flags them as non-compliant so you can fix them manually or automatically. |
|
|
|
Aggregates metrics, logs, and events from across AWS for real-time monitoring, dashboards, and automated alerting on governance non-compliance. |
|
|
Automation and enforcement |
Acts as a central notification system that watches for specific events in your AWS environment (such as when an S3 bucket has been created) and automatically triggers actions in response (such as by running a Lambda function to check if it has the required tags). Think of it as an if this happens, then do that automation engine. |
|
|
|
Runs your governance code (tag validation, security controls, remediation) in response to events without managing servers. |
|
|
|
Automates operational tasks across your AWS resources. In governance, it’s primarily used to automatically fix non-compliant resources—for example, if AWS Config detects an unencrypted database, Systems Manager can run a pre-defined script to enable encryption without manual intervention. |
|
|
Data protection |
Uses machine learning to automatically discover, classify, and protect sensitive data like personal identifiable information (PII) across your S3 buckets. |
|
|
|
Manages encryption keys for protecting data at rest, essential for high-impact data classifications. |
|
|
Analytics & Insights |
Serverless query service that analyzes data in Amazon S3 using SQL—perfect for querying CloudTrail logs to understand access patterns. |
|
|
Standardization |
Creates catalogs of pre-approved, governance-compliant resources that teams can deploy through self-service. |
|
|
ML Governance |
Provides specialized tools for governing machine learning operations including model monitoring, documentation, and access control. |
Understanding the data governance challenge
Organizations face complex data management challenges, from maintaining consistent data classification to ensuring regulatory compliance across their environments. Your strategy should maintain security, ensure compliance, and enable business agility through automation. While this journey can be complex, breaking it down into manageable components makes it achievable.
The foundation: Data classification framework
Data classification is a foundational step in cybersecurity risk management and data governance strategies. Organizations should use data classification to determine appropriate safeguards for sensitive or critical data based on their protection requirements. Following the NIST (National Institute of Standards and Technology) framework, data can be categorized based on the potential impact to confidentiality, integrity, and availability of information systems:
- High impact: Severe or catastrophic adverse effect on organizational operations, assets, or individuals
- Moderate impact: Serious adverse effect on organizational operations, assets, or individuals
- Low impact: Limited adverse effect on organizational operations, assets, or individuals
Before implementing controls, establishing a clear data classification framework is essential. This framework serves as the backbone of your security controls, access policies, and automation strategies. The following is an example of how a company subject to the Payment Card Industry Data Security Standard (PCI-DSS) might classify data:
- Level 1 – Most sensitive data:
- Examples: Financial transaction records, customer PCI data, intellectual property
- Security controls: Encryption at rest and in transit, strict access controls, comprehensive audit logging
- Level 2 – Internal use data:
- Examples: Internal documentation, proprietary business information, development code
- Security controls: Standard encryption, role-based access control
- Level 3 – Public data:
- Examples: Marketing materials, public documentation, press releases
- Security controls: Integrity checks, version, control
To help with data classification and tagging, AWS created AWS Resource Groups, a service that you can use to organize AWS resources into groups using criteria that you define as tags. If you’re using multiple AWS accounts across your organization, AWS Organizations supports tag policies, which you can use to standardize the tags attached to the AWS resources in an organization’s account. The workflow for using tagging is shown in Figure 1. For more information, see Guidance for Tagging on AWS.
Figure 1: Workflow for tagging on AWS for a multi-account environment
Your tag governance strategy
A well-designed tagging strategy is fundamental to automated governance. Tags not only help organize resources but also enable automated security controls, cost allocation, and compliance monitoring.
Figure 2: Tag governance workflow
As shown in Figure 2, tag policies use the following process:
- AWS validates tags when you create resources.
- Non-compliant resources trigger automatic remediation, while compliant resources deploy normally.
- Continuous monitoring catches variation from your policies.
The following tagging strategy enables automation:
While AWS Organizations tag policies provide a foundation for consistent tagging, comprehensive tag governance requires additional enforcement mechanisms, which we explore in detail in Part 2.
Conclusion
This first part of the two-part series established the foundational elements of implementing data governance on AWS, covering data classification frameworks, effective tagging strategies, and organizational alignment requirements. These fundamentals serve as building blocks for scalable and automated governance approaches. Part 2 focuses on technical implementation and architectural patterns, including monitoring foundations, preventive controls, and automated remediation. The discussion extends to tag-based security controls, compliance monitoring automation, and governance integration with disaster recovery strategies. Additional topics include data sovereignty controls and machine learning model governance with Amazon SageMaker, supported by AWS implementation examples.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Simplify network segmentation for AWS Outposts racks with multiple local gateway routing domains
Post Syndicated from Brianna Rosentrater original https://aws.amazon.com/blogs/compute/simplify-network-segmentation-for-aws-outposts-racks-with-multiple-local-gateway-routing-domains/
AWS now supports multiple local gateway (LGW) routing domains on AWS Outposts racks to simplify network segmentation. Network segmentation is the practice of splitting a computer network into isolated subnetworks, or network segments. This reduces the attack surface so that if a host on one network segment is compromised, the hosts on the other network segments are not affected. Many customers in regulated industries such as manufacturing, health care and life sciences, banking, and others implement network segmentation as part of their on-premises network security standards to reduce the impact of a breach and help address compliance requirements. Some AWS services also have network requirements that specify certain IP ranges to be used for endpoints, and may or may not support customers bringing their own IP pool (also called CoIP routing, see How to choose between CoIP and Direct VPC routing (DVR) modes on AWS Outposts rack for more information). Customers want the flexibility to use both routing modes (CoIP and DVR) on the same logical Outpost. With this new feature, AWS Outposts racks now support multiple LGW routing domains to meet subnetwork isolation and cloud service network requirements in an on-premises environment. For example, a leading automotive company deploys latency-sensitive manufacturing workloads on Outposts racks in a multi-AZ architecture for resiliency. This feature provides traffic separation between routing domains and enables both customer-owned IP (CoIP) and direct VPC routing (DVR) modes on the same logical Outpost.
In this post you will learn how to use multiple LGW routing domains on Outposts racks and considerations for implementation.
Overview
With the introduction of multiple LGW routing domains on Outposts, you can now create multiple routing domains and associate one or more VLANs with each routing domain. This allows you to integrate your Outposts rack into your existing on-premises network schema. Each LGW routing domain will have a unique LGW Virtual Interface (VIF) Group and an LGW Route Table, enabling logical network traffic isolation. You can have a mix of up to 10 active routing domains with route tables using either DVR or CoIP routing mode, and you can make changes to these routing domains as needed in a self-service fashion allowing for network flexibility as architectures are updated over time. These settings can be found in the AWS Outposts console under the Networking tab in the menu.
The following diagram shows an example of 3 VPCs, each with at least 1 subnet on the Outpost rack, and each VPC corresponds to its own routing domain. Each routing domain can then be associated with one or more VLANs, and one or more VPCs. A VPC can be associated with one or more LGW routing domain.

Figure 1 – Architecture diagram showing 3 routing domains
Walkthrough
Before creating a LGW routing domain, first you’ll need to create an LGW VIF group and an LGW route table. A local gateway routing domain is the association of a local gateway route table and local gateway VIF group. Each VIF group can be associated with one or more VLANs, but a route table can only be associated with one VIF group.
To create a LGW VIF Group, navigate to the AWS Outposts console, go to LGW virtual interfaces groups, and select Create VIF group. Enter your VIF details which include BGP and VLAN routing information, you must create 4 LGW VIFs per VIF group.

Figure 2 – Creating VIF group for RD1 routing domain
After creating your VIF group, create a LGW route table. You’ll have the option to use Direct VPC Routing (DVR) or Customer-owned IP address pool (CoIP) routing. If CoIP routing is selected, you’ll have the option to enter your CIDR before creating. A LGW route table’s routing mode cannot be changed after creating. However, you can disassociate a LGW route table from a VIF group and attach a new route table if you need to change the routing mode of a VIF group.

Figure 3 – Creating LGW route table for RD1 routing domain
After you’ve created your LGW route table and VIF group, you can proceed to the final step which is to create your LGW routing domain where you will associate the LGW route table and VIF group.

Figure 4 – Creating LGW routing domain for RD1
You can view and create up to 10 active routing domains through the AWS Outposts console under the Networking tab.

Figure 5 – Local Gateway (LGW) routing domains
Considerations
- Multiple LGW routing domains feature is only available on second-generation Outposts racks.
- Avoid overlapping IP addresses across subnetworks and local routing domains as those can create IP routing conflicts.
- A VIF group can only be associated to one LGW route table/routing domain at a time. A routing domain is the association of a VIF group and LGW route table.
- LGW routing domain will allow for logical local network traffic isolation, however all traffic will still travel across your local gateway Link Aggregation Control Protocol (LACP) Link Aggregation Group (LAG) to uplink into your on-premises network.
- Additional network isolation can be achieved through Virtual Routing and Forwarding (VRF) on Cisco platforms or Routing Instances on Juniper equipment, providing logical separation of routing tables and enabling secure multi-tenancy within the same physical infrastructure.
- You can associate a VPC to one or more LGW routing domains. You can self-serve to change VPC association as needed. Multiple on-premises VLANs can be connected to a single routing domain.
Conclusion
This post demonstrated how to configure multiple local routing domains on Outposts racks to integrate into your on-premises network. For more information see LGW routing domains section in the AWS Outposts user guide. Reach out to your AWS account team to learn more about Outposts racks network configuration options.
In addition to multiple LGW routing domains, we have also announced several updates to Outposts in the past week to help you meet digital sovereignty and local data processing needs. To learn more, read the following announcements:
To discuss Outposts with an expert on any of these topics, submit this form.
Metasploit Wrap-Up 01/16/2025
Post Syndicated from Simon Janusz original https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-01-16-2025
Persistence, dMSA Abuse & RCE Goodies
This week, we have received a lot of contributions from the community, such as h00die, Chocapikk and countless others, which is greatly appreciated. This week’s modules and improvements in Metasploit Framework range from new modules, such as dMSA Abuse (resulting in escalation of privilege in Windows Active Directory environments), authenticated and unauthenticated RCE modules, as well as many improvements and additions to the persistence modules and techniques.
New module content (13)
BadSuccessor: dMSA abuse to Escalate Privileges in Windows Active Directory
Authors: AngelBoy, Spencer McIntyre, and jheysel-r7
Type: Auxiliary
Pull request: #20472 contributed by jheysel-r7
Path: admin/ldap/bad_successor
Description: This adds an exploit for “BadSuccessor” which is a vulnerability whereby a user with permissions to an Organizational Unit (OU) in Active Directory can create a Delegated Managed Service Account (dMSA) account in such a way that it can lead to the issuance of a Kerberos ticket for an arbitrary user.
Control Web Panel /admin/index.php Unauthenticated RCE
Authors: Egidio Romano and Lukas Johannes Möller
Type: Exploit
Pull request: #20806 contributed by JohannesLks
Path: linux/http/control_web_panel_api_cmd_exec
AttackerKB reference: CVE-2025-67888
Description: This adds a new module for Control Web Panel (CVE-2025-67888). The vulnerability is unauthenticated OS command injection through an exposed API. The modules require Softaculous to be installed.
Prison Management System 1.0 Authenticated RCE via Unrestricted File Upload
Author: Alexandru Ionut Raducu
Type: Exploit
Pull request: #20811 contributed by Xorriath
Path: linux/http/prison_management_rce
AttackerKB reference: CVE-2024-48594
Description: This adds a new module for Prison Management System 1.0 (CVE-2024-48594). The module requires admin credentials, which are subsequently used to exploit unrestricted file upload to upload a webshell.
udev Persistence
Author: Julien Voisin
Type: Exploit
Pull request: #20796 contributed by h00die
Path: linux/persistence/udev
Description: This moves the udev persistence module into the persistence category and adds the persistence mixin.
n8n Workflow Expression Remote Code Execution
Author: Lukas Johannes Möller
Type: Exploit
Pull request: #20810 contributed by JohannesLks
Path: multi/http/n8n_workflow_expression_rce
AttackerKB reference: CVE-2025-68613
Description: This adds a new module for n8n (CVE-2025-68613). The vulnerability is authenticated remote code execution in the workflow expression evaluation engine. The module requires credentials to create a malicious workflow that executes system commands via a JavaScript payload.
Web-Check Screenshot API Command Injection RCE
Author: Valentin Lobstein [email protected]
Type: Exploit
Pull request: #20791 contributed by Chocapikk
Path: multi/http/web_check_screenshot_rce
AttackerKB reference: CVE-2025-32778
Description: Adds an exploit module for CVE-2025-32778, a command injection vulnerability in Web-Check’s screenshot API endpoint which allows unauthenticated remote code execution by injecting shell commands via URL query parameters in the /api/screenshot endpoint.
Accessibility Features (Sticky Keys) Persistence via Debugger Registry Key
Authors: OJ Reeves and h00die
Type: Exploit
Pull request: #20751 contributed by h00die
Path: windows/persistence/accessibility_features_debugger
Description: This updates the Windows sticky keys post persistence module to use the new persistence mixin.
WMI Event Subscription Event Log Persistence
Authors: Nick Tyrer <@NickTyrer> and h00die
Type: Exploit
Pull request: #20706 contributed by h00die
Path: windows/persistence/wmi/wmi_event_subscription_event_log
Description: Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.
WMI Event Subscription Interval Persistence
Authors: Nick Tyrer <@NickTyrer> and h00die
Type: Exploit
Pull request: #20706 contributed by h00die
Path: windows/persistence/wmi/wmi_event_subscription_interval
Description: Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.
WMI Event Subscription Process Persistence
Authors: Nick Tyrer <@NickTyrer> and h00die
Type: Exploit
Pull request: #20706 contributed by h00die
Path: windows/persistence/wmi/wmi_event_subscription_process
Description: Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.
WMI Event Subscription Logon Timer Persistence
Authors: Nick Tyrer <@NickTyrer> and h00die
Type: Exploit
Pull request: #20706 contributed by h00die
Path: windows/persistence/wmi/wmi_event_subscription_uptime
Description: Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.
Linux Chmod
Author: bcoles [email protected]
Type: Payload (Single)
Pull request: #20845 contributed by bcoles
Path: linux/armle/chmod and linux/aarch64/chmod
Description: Adds Linux ARM 32-bit / 64-bit Little Endian chmod payloads.
Enhancements and features (7)
- #20706 from h00die – Updated the Windows WMI to use a new way of managing persistence modules in Metasploit Framework. The Windows WMI module has been split into four modules, each representing their own technique.
- #20751 from h00die – This updates the Windows sticky keys post persistence module to use the new persistence mixin.
- #20785 from Chocapikk – This adds Waku framework support to the existing react2shell module. Waku is a minimal React framework which differs slightly compared to Node.js. The module maintains backward compatibility with existing Next.js targets while adding Waku support through a modular framework configuration system.
- #20786 from zeroSteiner – This updates the module code to merge the target Arch and Platform entries into the module’s top level data. Prior to this change module developers had to define Arch and Platform entries twice, once at the module level and again per individual target. This updates over 500 modules and removes that duplication.
- #20796 from h00die – This moves the udev persistence into the persistence category and adds the persistence mixin.
- #20853 from zeroSteiner – Bumps metapsloit-payloads to 2.0.239.
- #20855 from h00die – Adds additional ATT&CK references to persistence modules.
Bugs fixed (2)
- #20738 from Shubham0699 – This fixes an issue in the bailiwicked DNS modules that was causing the module to fail with a stack trace due to a programming error.
- #20847 from dwelch-r7 – This updates the auxiliary/scanner/ssh/ssh_login module to remove stale documentation, remove unnecessary characters that were printed in the output and update the correct documentation with the new information about key usage.
Documentation added (1)
- #20665 from basicallyabidoof – Adds documentation for the ipv6_neighbor_router_advertisement module.
You can always find more documentation on our docsite at docs.metasploit.com.
Get it
As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:
If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro
MikroTik CRS804 DDQ Announced 4-Port 400GbE Switch
Post Syndicated from Patrick Kennedy original https://www.servethehome.com/mikrotik-crs804-ddq-announced-4-port-400gbe-switch/
The new MikroTik CRS804 DDQ is a 1.6Tbps or 4x 400GbE device that is relatively small and low-cost for all of the bandwidth it provides
The post MikroTik CRS804 DDQ Announced 4-Port 400GbE Switch appeared first on ServeTheHome.
[$] A free and open-source rootkit for Linux
Post Syndicated from daroc original https://lwn.net/Articles/1053099/
While there are several rootkits that target Linux, they have so far not fully
embraced the open-source ethos typical of Linux software.
Luckily, Matheus Alves has been working to remedy
this lack by creating
an open-source rootkit called Singularity for Linux systems. Users who feel
their computers are too secure can install the Singularity kernel module in
order to allow remote code execution, disable security features, and hide files
and processes from normal administrative tools. Despite its many features,
Singularity is not currently known to be in use in the wild — instead, it
provides security researchers with a testbed to investigate new detection and
evasion techniques.
FS QSFP112 400Gbps DACs Mini Review
Post Syndicated from Rohit Kumar original https://www.servethehome.com/fs-qsfp112-400gbps-dacs-mini-review-nvidia-connectx-8/
We take a look at the QSFP112 400Gbps DACs that we purchased to use in the lab with our 400GbE networking gear
The post FS QSFP112 400Gbps DACs Mini Review appeared first on ServeTheHome.

