How to use AWS securely in Thailand? An explanation of security measures and operational design.

When using Amazon Web Services (AWS) at a Thai base, it's necessary to organize not only accounts, permissions, networks, and log monitoring, but also data placement both within and outside of Thailand, as well as the division of responsibilities with the Japanese headquarters. If connecting to AWS from local branches or factories, securing connection paths and establishing a communication system in case of incidents are also essential.

Furthermore, using the Thailand region does not automatically mean that all data will be stored in Thailand and that compliance with PDPA will be completed. You need to confirm the AWS services you will be using, the backup destination, and the data transfer to your Japanese headquarters or external services.

This article explains security measures for safely using AWS in Thailand, the Thai region and PDPA considerations, the division of roles between the Japanese headquarters and the Thai subsidiary, and key points to consider when choosing a support company.

Security challenges when using AWS in Thailand

When using AWS at a Thai branch, the design process includes not only cloud-based configuration but also alignment with management standards set by the Japanese headquarters, the local staffing structure, and connectivity to the branch's network. Even if the AWS environment is properly configured, ambiguous operational rules and responsibilities can lead to delays in configuration changes and overlooked unauthorized access.

There are differences between the standards set by the Japanese head office and the practices implemented locally in Thailand.

Even if security standards set by the Japanese head office are applied to the Thai subsidiary, there is no guarantee that they will be operated at the same level. While the head office may have established procedures such as multi-factor authentication, access request processes, and operation log storage, the local subsidiary may have different personnel and tools, resulting in some procedures not being implemented.

It's not enough to simply share the standards from headquarters; you need to adapt them into procedures that can be implemented at the Thai subsidiary. Clearly define who applies for and approves authorization, who is responsible for reviewing logs, and who to contact when an anomaly is detected, and establish common operational rules between headquarters and the local subsidiary.

A shortage of local staff leads to a reliance on individual expertise for authority management.

If a Thai subsidiary does not have a dedicated AWS specialist, the person in charge of internal systems and networks may also be responsible for managing the AWS account. When managed by a small number of people, administrator privileges may become concentrated in the hands of a few individuals, and unnecessary users and access keys may remain when those individuals leave or are transferred.

We will decide whether the head office or the local subsidiary will be responsible for adding, changing, or deleting users, and we will periodically review the permissions assigned to each user.

It is necessary to manage the connection routes from local bases and factories.

When connecting to AWS from an office or factory in Thailand, not only the AWS side but also the local router, firewall, terminals, and internet connection need to be managed. If AWS is accessible from a wide range of locations within the network, there is a risk that terminal infections or the leakage of authentication information could spread to the AWS environment.

The basic configuration involves limiting the network and users connecting to the service, allowing only necessary communications. When connecting via the internet, AWS Site-to-Site VPN can be used to configure an encrypted tunnel between the branch network and the Amazon Virtual Private Cloud (Amazon VPC).

Even when using AWS Direct Connect depending on the requirements for communication volume and stability, communication is not encrypted by default. You should design an encryption method according to your requirements, such as enabling MACsec on the dedicated connection port and on-premises equipment, or combining it with AWS Site-to-Site VPN.

AWS and its clients' security responsibilities

AWS security is based on a shared responsibility model where AWS and its clients each have their own responsibilities. AWS manages the entire cloud infrastructure, while clients manage the data stored on AWS, access permissions, and the settings of the services they use.

When using AWS at the Thai branch, in addition to this division of responsibilities, the scope of responsibility for the Japanese head office, the Thai subsidiary, and the support company will also be clearly defined.

The scope of the cloud infrastructure managed by AWS

AWS manages the infrastructure that makes up the cloud, including hardware, software, networks, and facilities. AWS is also responsible for access control to physical data centers and protecting the underlying equipment and networks.

However, the scope of AWS management varies depending on the service used. For example, with Amazon Elastic Compute Cloud (Amazon EC2), the user company is responsible for updating the guest OS, applying security patches, and managing installed applications. On the other hand, with managed services, the scope of AWS management expands. It is essential to confirm the boundaries of responsibility for each service used.

Scope of data, permissions, and settings managed by the user company

The companies using AWS manage the data handled on AWS, user access permissions, and network and service settings. Specifically, this includes setting permissions using IAM, controlling communication with security groups, encrypting data, storing logs, and backups.

Even with AWS infrastructure secure, security risks remain if excessive privileges are granted, settings are made publicly accessible, or unnecessary access keys are left unattended. Continuous management is essential, such as using temporary credentials for human access and applying the principle of least privilege.

Even if the Thai subsidiary operates its own AWS environment, the responsibility for configuration and data management does not automatically transfer to AWS. Based on the standards set by the Japanese headquarters, it is necessary to specify who will change the settings locally and who will verify them.

Determine the roles of the Japanese head office, the Thai subsidiary, and the support company.

After clarifying the responsibilities of AWS and the client company, we will allocate the client company's tasks to its Japanese headquarters, Thai subsidiary, and support company. If roles remain ambiguous, it may lead to delays in responding to permission changes or anomaly detection, or duplicate work performed by multiple organizations.

For example, the Japanese headquarters establishes security standards and management policies, while the Thai subsidiary checks user applications and the status of the local network. Support companies can be requested to handle AWS environment setup, monitoring, technical investigations, and recovery support.

However, even if you outsource the operation to a support company, the client company's management responsibility does not automatically transfer entirely. You should designate approvers for configuration changes, contacts for monitoring alerts, and decision-makers in the event of an incident, and document the division of responsibilities.

Security measures required for AWS environments in Thailand

In the AWS environment at our Thai base, we design everything from protecting authentication credentials and communication paths to data storage methods, monitoring configuration changes, and recovery from failures and attacks. If operations are shared between the Japanese headquarters and the Thai subsidiary, we also define who will implement and verify each measure.

Manage accounts, permissions, and networks.

Multi-factor authentication should be set up for access to AWS, and permissions should be granted only to users and those necessary for their work. AWS recommends using temporary credentials in cooperation with an identity provider for human access. Other measures include minimizing the issuance of long-term access keys and regularly reviewing unused users and permissions.

If the Japanese headquarters, the Thai subsidiary, and the support company share the same administrator account, it becomes difficult to identify who is performing the operation. Separate authentication information for each user and assign necessary permissions for configuration changes and troubleshooting based on their roles.

The network uses Amazon Virtual Private Cloud (Amazon VPC) subnets and security groups to restrict access and destinations. Even when connecting from offices or factories in Thailand, access is not granted uniformly to the entire site network; instead, the source, destination, and ports are limited to those necessary for business operations.

Encrypt data and monitor logs and configuration errors.

Data handled on AWS is encrypted both at rest and during transmission. When managing encryption keys with AWS Key Management Service (AWS KMS), restrict the users and services that can use the keys, separating data access permissions from key management permissions.

Encryption alone is insufficient to detect unauthorized operations or configuration changes. AWS CloudTrail records API operations, allowing for review alongside network communications and service logs. The log storage location is configured with access permissions and retention periods, and measures are taken to prevent tampering and ensure encryption. CloudTrail log files can also be encrypted using AWS KMS keys.

AWS Security Hub CSPM can be used to detect configuration errors. This service performs security checks and generates detection results for configuration errors in your AWS environment. If you operate multiple AWS accounts, you can choose a configuration where the Japanese headquarters sets standards and checks the configuration status including the accounts of the Thai subsidiary.

Simply receiving alerts is not enough to address anomalies. It's crucial to define who will review the alerts and under what conditions they will contact the Japanese headquarters or support company.

Establish backup and recovery procedures.

Backups are used not only to recover from failures, but also to restore operations from ransomware, user errors, and unauthorized configuration changes. The frequency of backups, retention period, and storage location are determined for each system and data set.

When deciding whether to continue operations at our Thai base, the key criteria are not only whether backups exist, but also whether we can recover within the necessary timeframe. Based on the impact on operations, the Japanese head office and the Thai subsidiary will agree on the acceptable range of data loss and the time it will take to resume operations.

The recovery procedure should include the person responsible for the operation, the approver, contact information, and post-recovery checklist. AWS Backup has a restore test feature that allows you to run the restore process according to your plan and review the results. Regular testing verifies the validity of your backup data and the feasibility of the procedure.

Thailand Region and PDPA Compliance Approach

Using the AWS Asia Pacific (Thailand) region (region code: ap-southeast-7) allows you to choose a configuration where your AWS data is located within Thailand. For PDPA compliance, you will need to review the storage location and transfer route of personal data, including the services used, backup destinations, and integration with external systems.

Check the services you are using and where your data is stored.

AWS allows companies to select the region where they want to store their content. If data storage is required within Thailand, select the Thailand region and then verify that the services you plan to use are available in that region.

The scope of verification extends beyond just the databases and storage where business data is stored. It also includes understanding the region where logs, backups, encryption keys, and monitoring data are stored. If data is replicated to another region for disaster recovery, the design must also take into account the fact that this will involve data transfer outside of Thailand.

Furthermore, the availability of services and features varies by region. If you need to supplement features unavailable in the Thailand region with those available in other regions such as Singapore or Japan, you should determine the configuration after confirming the data to be processed and the communication path.

Organize the transfer of data to the Japanese headquarters and overseas services.

Data from the Thai subsidiary may be transferred outside of Thailand through reporting to the Japanese head office, integration with group-wide systems, and transmission to overseas SaaS services. Even if the storage location on AWS is set to the Thailand region, it is not possible to accurately understand the data flow without including these integrations.

We will clearly define the source, destination, purpose of use, retention period, and organizations that can access information, including personal data. Furthermore, we will confirm the protective measures implemented at the destination, such as contracts with our Japanese headquarters and contractors, access rights, encryption, and log management.

In Thailand, regulations regarding the transfer of personal data abroad came into effect in March 2024. Since factors such as the level of protection at the destination and protective measures including rules within the corporate group are considered, the specific legal requirements should be confirmed with a Thai legal expert.

Simply using the Thai region does not make PDPA compliant.

The Thailand region is an option for storing data within Thailand. On the other hand, compliance with the PDPA involves establishing a comprehensive data management system, including the purpose of acquiring personal data, the scope of use, access rights, retention period, overseas transfer, and deletion methods.

Even if you select the Thailand region, the user company is responsible for classifying personal data, setting permissions, and managing logs. Do not make decisions based solely on the region's location; clearly define what data will be handled, by whom, for what purpose, and where it will be transferred.

By combining AWS's technical design with our internal data management rules, we can build a management system that is tailored to the actual operational needs of our Thailand office.

Operational system to prepare for incidents

Even with security measures in place, it's not always possible to completely prevent unauthorized access, misconfigurations, or system failures. To ensure a smooth response in the event of an incident at our Thai office, we will pre-define the responsibilities and communication procedures for our Japanese headquarters, Thai subsidiary, and support companies.

Determine the scope of responsibilities for the Thai subsidiary and the Japanese head office.

In incident response, the organization that initially identifies the anomaly may be different from the organization that determines the scope of impact and the response strategy. For example, the Thai subsidiary might check the status of users and the local network, while the Japanese headquarters determines the impact on business and external responses. Clearly defining these roles is crucial.

The scope of our response will be defined to include not only the AWS environment, but also local terminals, networks, and business systems. For example, the Thai subsidiary will be responsible for interviewing users and isolating terminals, while the Japanese head office will be responsible for reporting to relevant departments, deciding whether to shut down the system, and approving measures to prevent recurrence.

Specifying only the name of the person in charge may lead to delays in service due to transfers or absences. Document the department, substitute person, decision-making authority, and contact information, and update them regularly.

Standardize detection, communication, and recovery procedures and language.

Incident response procedures are defined in the following order: detection, initial confirmation, communication, impact assessment, containment, and recovery. Even if a monitoring alert is received, if the confirmation items and communication criteria are not clear, the initial response will be delayed.

For each type of alert, we set the urgency, the content of the initial check, contact information, and the deadline for action. We also clearly define the conditions under which to immediately contact the Japanese head office, such as in cases where business disruption or impact on personal data is suspected.

If the Japanese head office and the Thai subsidiary use different languages, standardize the reporting items and terminology. Recording the date and time of occurrence, the affected system, the detected information, the impact on business operations, the actions taken, and the following decision points in a common format will help minimize misunderstandings in translation and explanation. Include procedures for verifying normal operation after recovery and identifying the approver for resuming business operations.

Utilizing external monitoring and operational support

If it is difficult for the Thai subsidiary alone to handle continuous monitoring and technical investigations, we utilize external support companies. By outsourcing the confirmation of monitoring alerts and initial troubleshooting, we can supplement our incident response system while reducing the burden on local personnel.

We will differentiate between tasks to be outsourced and those to be kept in-house, and establish communication channels between the Japanese head office, the Thai subsidiary, and the support company. The specific scope of work will be confirmed when selecting the support company, as explained in the next chapter.

Key points for choosing an AWS security support company in Thailand

When outsourcing AWS operations for a Thai base, it's important to check the scope of support, including not only the AWS environment but also the local network and coordination with the Japanese headquarters. Don't just rely on the availability of monitoring services; compare the extent of investigation and recovery support you can request after an anomaly is detected.

Can AWS and local networks be supported in an integrated manner?

In configurations where AWS is used from offices or factories in Thailand, both the AWS settings and the local network affect the security and stability of communications. Companies that only provide support for AWS environments may have to request investigations into the cause of connection failures or unauthorized communications from multiple service providers.

When selecting a support company, check whether they can coordinate not only the AWS environment but also local lines and network equipment. If multiple companies are responsible for different aspects, the ability to coordinate communication with each company and conduct root cause investigations should also be a selection criterion.

Can you handle both the Japanese head office and the Thai subsidiary?

The Japanese headquarters manages security standards, budgets, and the overall impact on the system, while the Thai subsidiary understands the user and local network situation. The support company is required to collect necessary information from both sides and report separately on the technical situation and its impact on operations.

In addition to supported languages, contact information, reporting methods, and operating hours are also important factors to consider when selecting a provider. Having a system in place that allows for confirmation in English or Thai with the Thai subsidiary and reporting to the Japanese head office in Japanese through a single point of contact helps minimize duplication of explanations and misunderstandings.

We will also confirm the languages ​​in which deliverables such as design documents, configuration information, operating procedures, and incident reports can be received. A company that can keep records of the details of the response and the history of configuration changes is suitable so that operations can continue even if the person in charge changes.

Can we entrust them with everything from monitoring and subsequent investigation to recovery and improvement?

The scope of monitoring services may be limited to alert notifications, or it may include initial troubleshooting and recovery support. For contracts where the client company is responsible for post-notification investigations, AWS engineers must be stationed at either the Thai subsidiary or the Japanese headquarters.

Before signing a contract, clearly define the scope of services you can request, including alert verification, impact investigation, root cause identification, configuration changes, and recovery work. Also, specify the approval process for emergencies and the authority granted to the support company.

The scope of support after recovery is also a selection criterion. If the system allows for reporting of the cause of the incident and the response, as well as reviewing settings, adding monitoring items, and proposing measures to prevent recurrence, the incident can be used to continuously improve operations.

Serverworks and IIJ Group provide support for AWS security measures in Thailand.

Serverworks and IIJ Global Solutions (Thailand) Co., Ltd. (IIJ GS Thailand) offer "IIJ Managed Cloud for AWS Powered by Serverworks." By combining Serverworks' AWS technology and operational know-how with the IIJ Group's local business infrastructure and network capabilities in Thailand, they support the design and construction of AWS environments, network connectivity with local offices, operational monitoring, cost management, and operational automation.

Serverworks also provides 24/7/365 operational monitoring of AWS environments. When a critical security alert is detected, it will be notified to a pre-designated contact. The scope of response after notification, such as root cause investigation, recovery support, and configuration review, will vary depending on the contract.

If you are experiencing issues with your AWS environment, local network, or monitoring system at your Thai base, please contact us to discuss your current situation and identify areas for improvement.