Ransomware không chỉ làm mất quyền truy cập vào dữ liệu quan trọng mà còn gây ra những tổn thất tài chính đáng kể cho các doanh nghiệp. Khi dữ liệu bị mã hóa, doanh nghiệp không chỉ mất khả năng hoạt động bình thường mà còn phải đối mặt với áp lực từ phía khách hàng và đối tác do không thể cung cấp dịch vụ. Thêm vào đó, việc phục hồi sau một cuộc tấn công ransomware thường đòi hỏi thời gian và chi phí lớn, từ việc thuê chuyên gia bảo mật, mua sắm thiết bị mới, đến việc mất dữ liệu vĩnh viễn nếu không có bản sao lưu đầy đủ.

Cụ thể, trong trường hợp của VNXXX, một công ty chứng khoán hàng đầu tại Việt Nam, cuộc tấn công ransomware gần đây không chỉ tạm thời làm gián đoạn hoạt động kinh doanh mà còn ảnh hưởng đến niềm tin của khách hàng và đối tác. Điều này chứng minh rằng không một tổ chức nào, kể cả những doanh nghiệp lớn và có hệ thống bảo mật tưởng chừng như vững chắc, cũng có thể trở thành mục tiêu của các cuộc tấn công mạng.

Trước tình hình đó, giải pháp Microsegmentation của Akamai đóng một vai trò quan trọng trong việc phòng chống và giảm thiểu rủi ro từ ransomware. Bằng cách phân chia mạng thành các phân đoạn nhỏ, giải pháp này giúp cô lập các cuộc tấn công, ngăn chặn sự lây lan của mã độc và bảo vệ dữ liệu quan trọng của doanh nghiệp. Sự hợp tác giữa Akamai và Techcity, đối tác tại Việt Nam, mang lại cho các doanh nghiệp cơ hội tiếp cận với các giải pháp an ninh mạng tiên tiến, giúp họ vượt qua khủng hoảng và phòng thủ chắc chắn hơn trước mối đe dọa ngày càng tăng này.

Kết luận, trong khi hậu quả của ransomware đối với các tổ chức và doanh nghiệp là không thể xem thường, sự hợp tác giữa Akamai và Techcity trong việc triển khai giải pháp Microsegmentation mở ra một giải pháp hiệu quả và chắc chắn trước các rủi ro an ninh mạng. Bằng cách giúp các tổ chức kiểm soát chặt chẽ quyền truy cập và phân loại dữ liệu, giảm thiểu khả năng bị xâm nhập và lây lan của mã độc, Akamai và Techcity đang góp phần tạo nên một môi trường kinh doanh an toàn hơn cho các doanh nghiệp Việt Nam.

Trong thời đại số, nơi mối đe dọa từ mạng ngày càng tinh vi và khó lường, việc đầu tư vào các giải pháp bảo mật thông minh, linh hoạt như Microsegmentation không chỉ là một lựa chọn khôn ngoan mà còn là một yêu cầu cần thiết. Sự kết hợp giữa công nghệ tiên tiến của Akamai và sự chuyên nghiệp, tận tâm từ Techcity chắc chắn sẽ là chìa khóa giúp các doanh nghiệp Việt Nam bảo vệ mình khỏi những hậu quả tiêu cực của ransomware, đồng thời duy trì sự ổn định và phát triển bền vững trong tương lai.

The post Hậu Quả Đau Lòng của Ransomware và Hành Trình Vượt Qua cùng Akamai và Techcity first appeared on Techcity Company Limited.

Với những hậu quả của các cuộc tấn công ransomware, ta thấy rõ mức độ ảnh hưởng sâu rộng của chúng đến doanh nghiệp. Từ việc làm tê liệt hệ thống, ảnh hưởng đến hoạt động kinh doanh hàng ngày, đến việc gây ra những tổn thất tài chính đáng kể và làm mất lòng tin của khách hàng. Đối với VNXXX, những hậu quả này càng trở nên nghiêm trọng hơn khi họ phải đối mặt với áp lực từ thị trường tài chính nơi uy tín là vô cùng quan trọng.

Trong bối cảnh đó, giải pháp Microsegmentation của Akamai, được giới thiệu như một phương pháp hiệu quả để phòng chống và hạn chế tối đa sự lây lan của ransomware. Bằng cách phân chia mạng thành các phân đoạn nhỏ và quản lý chặt chẽ việc truy cập, Microsegmentation giúp cô lập và giảm thiểu rủi ro từ các cuộc tấn công, đồng thời bảo vệ dữ liệu quan trọng của doanh nghiệp. Thông tin chi tiết về giải pháp Microsegmentation vui lòng xem thêm tại Akamai Guardicore Segmentation – Techcity Company Limited

Techcity, đối tác chiến lược của Akamai tại Việt Nam, đóng vai trò quan trọng trong việc tư vấn và triển khai giải pháp Microsegmentation. Sự hợp tác giữa Akamai và Techcity không chỉ mang lại giải pháp an ninh mạng tiên tiến cho các doanh nghiệp Việt Nam mà còn giúp họ nhanh chóng phục hồi và tái thiết sau các cuộc tấn công, bảo vệ doanh nghiệp trước những rủi ro an ninh mạng trong tương lai.

Tóm lại, trong khi hậu quả của ransomware đối với các doanh nghiệp như VNXXX là rất lớn, sự hợp tác giữa Akamai và Techcity trong việc áp dụng giải pháp Microsegmentation mở ra một hướng đi mới trong việc phòng thủ và bảo vệ doanh nghiệp trước mối đe dọa ngày càng tăng này, đảm bảo an toàn thông tin và ổn định kinh doanh.

The post Giải Pháp Công Nghệ Trước Mối Đe Dọa Ransomware: Vai Trò Của Microsegmentation first appeared on Techcity Company Limited.

Một số cuộc tấn công nổi bật trong năm qua bao gồm cuộc tấn công vào hệ thống POS của NCR Aloha bởi nhóm ALPHV (BlackCat), làm gián đoạn các hoạt động của nhiều cửa hàng ăn uống​​; cuộc tấn công vào dịch vụ chuyển giao tập tin MOVEit bởi nhóm Clop, ảnh hưởng đến nhiều tổ chức trên toàn cầu (nguồn digitalguardian)​​; và vụ việc tại Đại học Hawaii, nơi đã phải trả tiền chuộc cho nhóm NoEscape​​.

Với tình hình đó, giải pháp Microsegmentation của Akamai nổi bật như một phương pháp phòng thủ hiệu quả. Microsegmentation là việc tạo các khu vực bảo mật trong mạng để kiểm soát việc truy cập và giảm thiểu diện tích tấn công, giúp ngăn chặn và hạn chế khả năng lây lan của mã độc trong mạng nội bộ. Bằng cách áp dụng giải pháp này, các tổ chức có thể cô lập các hệ thống và ứng dụng quan trọng, hạn chế tối đa rủi ro và hậu quả của một cuộc tấn công ransomware.

Mặc dù không tìm thấy thông tin cụ thể về sự cố tấn công VNXXX, nhưng dựa trên các cuộc tấn công gần đây và phương pháp phòng vệ, ta có thể rút ra một số bài học quan trọng. Đầu tiên, sự cần thiết của việc cập nhật và bảo dưỡng hệ thống để khắc phục các lỗ hổng bảo mật. Tiếp theo, việc triển khai giải pháp Microsegmentation để giảm thiểu tác động của các cuộc tấn công và cô lập chúng khỏi các tài nguyên quan trọng khác. Cuối cùng, việc chuẩn bị kế hoạch phản ứng sự cố cũng như phục hồi sau tấn công là điều cần thiết để giảm thiểu thiệt hại và nhanh chóng khôi phục hoạt động.

Khi nhắc đến việc triển khai giải pháp Microsegmentation của Akamai tại Việt Nam, Công ty TNHH Techcity đóng một vai trò quan trọng như là đối tác chính thức. Sự hợp tác giữa Akamai và Techcity mang lại cho các tổ chức và doanh nghiệp tại Việt Nam cơ hội tiếp cận các giải pháp bảo mật tiên tiến, giúp họ bảo vệ dữ liệu quan trọng và hệ thống mạng trước các mối đe dọa ngày càng tinh vi. Techcity, với đội ngũ chuyên gia giàu kinh nghiệm và năng lực tư vấn, triển khai cao, đảm bảo quá trình tích hợp Microsegmentation vào hệ thống IT của khách hàng diễn ra suôn sẻ và hiệu quả, đồng thời đáp ứng nhanh chóng và linh hoạt với các yêu cầu cụ thể.

Việc lựa chọn đối tác phù hợp như Techcity cho phép các doanh nghiệp tận dụng triệt để lợi ích của Microsegmentation, không chỉ ngăn chặn sự xâm nhập từ bên ngoài mà còn kiểm soát và hạn chế khả năng lây lan của mã độc từ bên trong. Điều này giúp tạo lập một môi trường IT an toàn, linh hoạt và có khả năng chống chịu với các cuộc tấn công ransomware, đồng thời bảo vệ tài sản số và uy tín của doanh nghiệp trước các rủi ro tiềm ẩn.

Kết luận, việc áp dụng giải pháp Microsegmentation của Akamai thông qua sự hợp tác với Techcity là một bước đi chiến lược và thiết thực để nâng cao khả năng phòng thủ trước ransomware cho các tổ chức và doanh nghiệp tại Việt Nam. Sự kết hợp giữa công nghệ tiên tiến của Akamai và kinh nghiệm triển khai của Techcity tạo thành một giải pháp mạnh mẽ, giúp bảo vệ hệ thống mạng một cách toàn diện và hiệu quả, làm giảm đáng kể rủi ro và hậu quả do các cuộc tấn công ransomware gây ra.

The post Phòng Thủ Chống Ransomware: Giải pháp nào cho doanh nghiệp? first appeared on Techcity Company Limited.

Monitoring Options

• DBMS monitoring extensions: Extensions or add-ons within the database layer that provide insights on query efficiency, database connections, and more.
• Cloud provider monitoring tools: Most cloud providers include free monitoring for your database infrastructure to show metrics like CPU usage and network transfer. Some cloud providers also offer database monitoring as part of their managed database service
• External monitoring tools: Database-specific monitoring tools are designed to provide more insight beyond metrics like your underlying infrastructure’s CPU usage or network traffic. There is a wide variety of these tools available that fit different workloads. Here are a few examples of free open source database monitoring tools
  • Prometheus & MySQL Exporter: Built on top of the popular open source infrastructure monitoring tool, Prometheus, MySQL Server Exporter allows you to create a series of collector flags.
  • VictoriaMetrics: A time series database and monitoring solution to help process real-time metrics using the PromQL, MetricsQL, and Graphite query languages Best suited for small to medium size database environments Deploy via the Linode Marketplace
  • Percona Monitoring & Management: Optimize database performance and track behavior patterns for MySQL, PostgreSQL, and MongoDB Deploy via the Linode Marketplace.

When should you separate your database monitoring layer?

If you just want to keep an eye on CPU usage, relying on more standard infrastructure monitoring solutions will suffice. If you want to be able to observe performance at the query or table level, or check database logs during very specific points in time, an external monitoring tool will give you additional insight that can benefit your application

The post Designing Database Architecture – Incorporating Monitoring first appeared on Techcity Company Limited.

To address this issue, an architecture that implements database sharding can be used With sharding, a single, large table is split into multiple smaller tables The process of splitting a table is referred to as partitioning. When stored across multiple servers, these smaller tables are referred to as shards The databases in your cluster each store one of the shards Together, the databases in the cluster constitute your full data set For example, if a human resources application stored employee records for 1,000 companies, but found that the dataset size was too big for a single table, then the records could be split into two shards representing 500 companies each

MySQL NDB Cluster is a solution that provides automatic sharding for MySQL The diagram below shows
an example of how a MySQL NDB Cluster would fit into the example web application. This diagram omits the load balancer, cloud firewall, and web server cluster as those remain the same:

Database Sharding for Large Data Sets

The MySQL NDB Cluster in this diagram provides three MySQL servers that accept read and write SQL commands from the web servers The number of these servers can be horizontally scaled to meet demand and provide failover These servers do not store data Instead, they update and retrieve records from a separate set of data nodes.

The data nodes store shards of the dataset and run the ndbd data node daemon process Each shard can have multiple replica nodes, and you can configure how many replicas per shard there should be. The total number of data nodes is equal to the number of shards multiplied by the number of replicas per shard In the diagram above, there are two shards, and two replicas per shard (a primary replica and a secondary replica), for a total of four data nodes Having multiple replicas per shard allows for recovery for failing nodes, and this recovery process is automatic (similar to MySQL Group Replication).

Using sharding can offer very high scaling of dataset size, but it can also make your application logic more complex. In particular, you need to carefully configure how your data is partitioned into multiple shards, because this decision impacts overall database performance Sharding requires a more in-depth understanding of your database and the underlying infrastructure.

The post Designing Database Architecture – Horizontal Scaling with MySQL NDB Cluster and Database Sharding first appeared on Techcity Company Limited.

In the previous section, a two-server solution was presented that separated the web server from the database server While it did not solve vertical scaling’s problems, the separation of web servers and database servers is an important step towards creating a horizontal scaling solution.

In a horizontal scaling solution, the single web server is replaced with a high availability cluster of web servers, and the single database server is replaced with another, separate high availability cluster of database servers By having two separate clusters in your architecture for these services, you can horizontally scale them independently of each other and choose server instances with different hardware that is better suited for each workload.

There are several different ways to architect your database cluster, each with varying degrees of complexity and different trade-offs. This section and the diagram below illustrate how to use MySQL replicas to facilitate high availability.

Multi-Replication for Application High Availability

In the diagram above, a load balancer receives traffic from the Internet. A load balancer is a service that forwards and distributes traffic among another set of servers. Cloud providers generally offer load balancing as a service (Linode’s NodeBalancer solution is pictured). This service can also be implemented with open source software, including HAProxy, NGINX, and the Apache HTTP Server.

Before the forwarded traffic arrives at your web servers, it is intercepted by a cloud firewall. The cloud firewall lifts the firewalling burden from the operating system to the network level. Many cloud providers offer managed cloud firewalls, but this service can also be implemented with open source software on commodity hardware.

After being filtered, the traffic is distributed among a cluster of web servers. In many cases, these web servers can all be identical clones of each other. You can add or remove web servers in this cluster as needed to handle scaling traffic demand, which is an example of horizontal scalability. If a server fails, the load balancer will re-route traffic to other healthy servers, so the service remains available. Server creation can be automated with configuration management and Infrastructure as Code (IaC) tools like Ansible and Terraform.

The web servers in turn request data from a database cluster Unlike the web servers, the database server are not all identical in function In particular, only one database is set to receive write operations from the web application This server is designated as the primary database For example, if you operated a news website, the new articles that your writers published would be added to the database on this server.

The other databases in this cluster act as replicas of the primary database These servers receive all data added to the primary database through an asynchronous process Because this process is asynchronous, write operations on the primary database are still fast to execute These servers then receive all read operations from the web server cluster.

MySQL offers tools to help add new replicas to the cluster when needed, so your applications’ read operations can be horizontally scaled However, there is only one primary database in this architecture, so write operations cannot also be horizontally scaled. Still, this architecture can offer significant benefits to certain kinds of applications. In the news organization website example, the source of high-traffic demand is from readers of the website, not from writers adding articles. This traffic pattern aligns with the trade-offs in this setup.

There are a few other notable issues with this architecture First, when a new write operation is received by the primary database, it immediately persists the updated records The database does not wait for the replication process to complete, because that is asynchronous This means that in the event of a primary database failure, the replicas might not have the most recently updated records Also, when the primary database fails, it acts as a single point of failure for write operations Still, read operations will continue on the replicas in this scenario, so a website can continue to display existing content If the primary database fails, MySQL provides tools to manually promote one of the replicas to the position of the new primary database, after which write operations can resume.

Enhancements and alternative replication solutions exist to address these issues:

• MySQL replication can be configured to be semisynchronous instead of asynchronous This means that the primary database will wait for at least one replica to process new write operations before they are persisted Because at least one replica will have the latest data, you can be sure that you will not lose data in the event of a primary database failure However, semisynchronous replication is slower than asynchronous replication.
• MySQL Group Replication is a replication solution in which the database servers automatically coordinate with each other For example, in the event of a primary database outage, a replica server is automatically promoted to the new primary position. MySQL Group Replication can be configured with a single primary database, or it can be configured to have multiple primary databases that receive write operations. However, maintaining multiple primary databases involves other trade-offs.
• InnoDB Cluster bundles a MySQL Group Replication cluster with MySQL Router, which facilitates routing traffic from the web servers to the database cluster, and MySQL Shell, which is an advanced administration client for the cluster
• Galera is a multi-primary database solution where all databases in the cluster can receive write and read operations using completely synchronous replication between them It is also compatible with forks of MySQL like MariaDB and Percona.

The post Designing Database Architecture – Horizontal Scaling with MySQL Replication first appeared on Techcity Company Limited.

Provisioning a LAMP stack on a single node can be done in two steps

1. Deploy a Linux server, then install the other three software packages via your distribution’s package manager. Once the stack is provisioned, your web application’s code should be installed and configured. This work can often be automated with open source tooling; for example, WP-CLI can be used to install WordPress on a server
2. You need to consider the network security and availability of your server. Many cloud providers offer network filtering to prevent or reduce the impact of denial-of-service and other kinds of network attacks. However, it’s still important to fine-tune your network security configuration with a firewall.

In this section’s example architecture, the firewall is a process that runs on your server. The firewall intercepts network packets when they are first processed by the operating system and only allows traffic on certain network ports to proceed. For a web application, your firewall would allow HTTP (port 80) and HTTPS (port 443) traffic. Linux and other operating systems have built-in firewall options, like iptables, ufw, and FirewallD

Single Node LAMP Stack with Cloud Firewall

The resulting setup has one server running the LAMP stack where network traffic is filtered by a firewall also

running on the server There are limitations for this setup:

• Growth and scaling: With one server, you’re confined to that server’s memory, compute, and disk space resources. If your website starts seeing more traffic, you might need to increase the memory, compute, and/or disk space of the server to handle the load This is referred to as vertical scaling This process can vary in difficulty, depending on your cloud provider’s tooling, or on hardware availability for on-premise deployments. Vertical scaling can only offer a limited solution for capacity, as there are upper limits on the resources for a single server.
• Availability: Operating a single server means that there is a single point of failure for your web application. If the server needs hardware maintenance, or if one of the software components in the stack halts unexpectedly, then your web application will not be available To some extent, the issue of traffic growth can be addressed by moving the database to its own server, as in the following diagram:

Vertical Scaling with Separate Web and Database Nodes

By doing this, the compute, memory, and disk space needs of your web server and database can be adjusted independently This is still an example of vertical scaling, and it does not resolve availability issues.

The post Designing Database Architecture – Single Server Deployment and Vertical Scaling first appeared on Techcity Company Limited.

The typical real-world use case for a database is to store and handle structured information as part
of an application’s software stack. The foundation of a simple web application is the operating system of your server, with a web server, database, and application code layer running on top of it The OS provides basic networking functionality that the web server relies on to serve content In the code layer, a programming language and application software framework are used to direct the client-side UI in your users’ browser. We can look at a server running a WordPress site to illustrate these concepts:

Single Node Web Server Architecture

A WordPress site commonly leverages a software stack called LAMP, which is composed of the Linux operating system, Apache HTTP web server, MySQL database, and PHP programming language LAMP is one of the most popular web application software stacks in use. There are also alternatives to the LAMP stack. For example, you can use Python and an associated web application framework (like Django) instead of PHP Or, you can use the NGINX web server instead of Apache; this is referred to as the LEMP stack (the “E” comes from the pronunciation of NGINX, which is “Engine X”) There are many other variations of this concept, but the following scenario focuses on a traditional LAMP stack.

The post Designing Database Architecture – Single Node Web Server Architecture first appeared on Techcity Company Limited.

Many websites and web applications can be operated with a single-server configuration, where your database exists on the same server as all of the application’s other software components. This can be appropriate when your server (possibly when paired with external storage, like block storage) has enough compute and storage resources to accommodate your application’s data and traffic. This approach is fine for smaller, general use websites that might host some forms and media files. For example, a WordPress blog can run well on a single-server setup.

As your application’s features and data requirements grow, your database infrastructure needs additional flexibility and scalability to meet the performance expectations of your users or customers. Necessary changes could include moving the database to its own compute instance(s), or designing an advanced architecture with replicas, read-only instances, sharding, and/or other components These changes can enhance both the performance and security of your database.

Application performance is a shared responsibility Even if you or your team doesn’t currently prioritize conversion rates, poor application performance will come back to haunt you in other ways, including: decreased user trust, violation of your application’s SLA (the guaranteed availability of your services), and an increase in support tickets.

Research into human response indicates applications have roughly 100 milliseconds (ms)—one third of the time it takes to blink— before users feel like they’re waiting for a response

Lee Atchison
Caching at Scale with Redis

To help get you started, here are five examples of database-specific reference architecture that show how these setups differ, and their benefits. Please read more next post!

The post Designing Database Architecture first appeared on Techcity Company Limited.

Strengths

• “Ring” Architecture: Multiple nodes are organized logically in a “ring ” Each node can accept read and write requests so there is no single point of failure
• Ease of Use: Cassandra’s query language, CQL, has a syntax similar to traditional SQL and has a reduced learning curve for developers switching from a SQL database
• Write Speed: Cassandra is efficient for writing very large amounts of data. When performing a write operation, replicas of a new record are stored across multiple cluster nodes and these replicas are created in parallel Only a subset of those nodes need to complete a replica update for the write operation to be considered successful, which means that the write operation can finish sooner.

Weaknesses

• Read Time: Records in a Cassandra database are assigned a primary key attribute The value of the primary key determines which cluster nodes a record is stored on When querying data by primary key, read performance is fast, because the node that stores the data can be found quickly However, querying data using attributes other than the primary key is slower
• Not ACID-compliant out of the box. Instead, Cassandra offers several levels of trade-off between data consistency and availability for developers Use Cases: Personalization Engines, Content Management, Games, IOT Applications

The post Overview of Popular DBMSeS – Cassandra first appeared on Techcity Company Limited.

Strengths

• Speed: Since Redis only stores data in memory, it’s a highly-performant database that rapidly returns results
• Benchmarking: The built-in benchmark tool, redis-benchmark, provides insights on the average number of requests your Redis server is able to handle per second
• Ease of Use: Supports a variety of extensions, including RediSearch, which provides full text search for a Redis database

Weaknesses

• Memory Restrictions: Since Redis is an in-memory store, all data must fit within your available memory
• Rigidity: Redis doesn’t have a query language, and entering functions via the available commands can limit your ability to customize results
• Not ACID compliant out of the box. Additional configuration is required

Use Cases: Caching, Real-Time Data Updates

The post Overview of Popular DBMSeS – Redis first appeared on Techcity Company Limited.

Strengths

• Scalability: It’s in the name: Mongo, short for “humongous,” is built to store large volumes of data
• Search Flexibility: Supports graph search, geo-search, map-reduce queries, and text search
• Flexible Data Options: More functionality for temporary tables to support complex processes or test new applications/features without needing to switch databases

Weaknesses

• Concurrent Multi-Location Data Write Operations: Updating a consistent field in several locations (e g a commonly used location) can cause lags in performance compared to a relational database
• Query Formatting: MongoDB can have a steeper learning curve for developers who are familiar with other databases because queries are written with a JSON syntax, instead of SQL

Use Cases: Personalization Engines, Content Management, Games, IOT Applications

The post Overview of Popular DBMSeS – MongoDB first appeared on Techcity Company Limited.