"Innovation of Window Server 2022 : Run business critical workloads in Azure, on-premises and at the edge."

For customers with Software Assurance, Azure Hybrid Benefit for Windows Server allows you to use your on-premises Windows Server licenses and run Windows virtual machines on Azure at a reduced cost.

You can use Azure Hybrid Benefit for Windows Server to deploy new virtual machines with Windows OS. This article goes over the steps on how to deploy new VMs with Azure Hybrid Benefit for Windows Server and how you can update existing running VMs.
Detail more for click link : https://docs.microsoft.com/en-us/azure/virtual-machines/windows/hybrid-use-benefit-licensing

หากสนใจสินค้าStock and sale หรือสอบถามเพิ่มเติมสามารถติดต่อ This email address is being protected from spambots. You need JavaScript enabled to view it. ทางเรามีจำหน่ายสินค้า Dell commercial Server with ROK Dell Commercial Microsoft Window
Remark :สินค้าSNSไม่สามารถออกหนังสือราชการหรือเอกสารใดๆได้นะคะ

เทคโนโลยีของ ROK Dell Commercial Microsoft Window

Windows Server ROK 2019 ต่อยอดสู่ Windows Server ROK 2022 โดยพัฒนาเป็นระบบปฏิบัติการระยะยาว
ยกระดับความปลอดภัยที่สูงมากขึ้น  (Long-Term Servicing Channel หรือ LTSC)

โดยฟีเจอร์ใหม่แบ่งออกเป็น 3 กลุ่มคือ

  ✨ ความปลอดภัย ฟีเจอร์หลักคือ secured-core server ยกระดับความปลอดภัยหลายด้าน

  ✨ การทำงานแบบไฮบริดร่วมกับบริการของ Azure เช่น Azure Arc และ Storage Migration Service เพื่อให้ย้ายงานไป-กลับ ระหว่าง on premise กับ on cloud ได้ดีกว่าเดิม

  ✨ ฟีเจอร์ด้าน Windows Containers และ Kubernetes โดยฟีเจอร์สำคัญคือลดขนาดภาพ (Image) ลง

Windows Server 2022 ยังขยายการรองรับเครื่องขนาดใหญ่มากๆ เช่น ฐานข้อมูล SQL Server  ซึ่ง Dell Server ของ VST ECS มีสินค้าพร้อมจำหน่าย  หากสนใจสินค้าStock and stock หรือสอบถามเพิ่มเติมสามารถติดต่อ  This email address is being protected from spambots. You need JavaScript enabled to view it.  สินค้าSNSไม่สามารถออกหนังสือราชการหรือเอกสารใดๆได้นะคะ

การป้องกันความปลอดภัยให้กับ Real-Time APIs ด้วย NGINX Advanced Security Solution

ถ้าคุณได้ติดตามข่าวสาร เกี่ยวกับเทคโนโลยี ในปัจจุบันดูเหมือนว่า จะเห็นข่าวการละเมิดความปลอดภัยอยู่เสมอ ซึ่งในการละเมิดความปลอดภัยมีรูปแบบการโจมตีบน API มากขึ้นเรื่อย ๆ สาเหตุ เกิดจากที่ Application ในปัจจุบัน มีในการสื่อสารหรือแลกเปลี่ยนข้อมูลกันผ่านการใช้งาน API เป็นหลัก ทำให้เป็นช่องทางในการโจมตีได้ง่ายขึ้นด้วยเช่นกัน

ในรายงาน The State of Application Strategy in 2021 จากทาง F5 Network ผลจากจำนวนผู้ตอบแบบสอบถาม มากกว่า 58% บอกว่า พวกเขากำลังสร้างระบบ API สำหรับแอปพลิเคชันสมัยใหม่ (Modernize Applications) ด้วยการเพิ่มขึ้นของ DevOps, Cloud และ Microservice ทำให้แอปพลิเคชันและ APIs ต้องรองรับการใช้งานในสภาพแวดล้อมที่สามารถขยายตัวได้ง่าย และสามารถทำงานได้ทุกสภาพแวดล้อม อย่างเช่น

• โครงสร้างพื้นฐานแบบ On-Premise, Cloud และ Hybrid Cloud
• สภาพแวดล้อมแบบ Development, Testing, Stagging, Sandbox และ Production
• Internal APIs ที่อำนวยความสะดวกในการสื่อสารของนักพัฒนาโปรแกรมและปลดล๊อค ข้อมูลบางอย่างให้ง่ายต่อการเข้าถึง
• External APIs ที่เปิดให้บริการกับ Customer, Partner และ Third-party เข้ามาใช้งานในการพัฒนาระบบ

API Gateway จะเป็นตัวกลางในการสื่อสารของทราฟฟิค API โดยฟังก์ชันในการทำ Request Routing, Authentication/Authorizing API Client และใช้งาน Rate Limits สำหรับการป้องกันแต่ละ API ของ Services กรณีที่เกิด Overload ในการใช้งาน APIs ซึ่งลูกค้า NGINX จำนวนมากประสบความสำเร็จในการติดตั้ง API Gateway ข้ามระบบสภาพแวดล้อมแบบกระจายตัว (Distributed Environments)

จากรายงาน 2021 Application Protection Report จากทาง F5 Network นั้น เกือบสองในสามของเหตุการณ์ที่ถูกโจมตีและถูกเปิดเผยนั้น สาเหตุเกิดจากมาจาก​ API ไม่มีกลไกการตรวจสอบสิทธิ์หรือการได้รับอนุญาต (Authentication or Authorization).

โดยที่ NGINX Controller API Management Module ได้มีการเตรียมฟังก์ชันหลากหลายในการป้องกัน API อย่างเช่น

•  Rate Limiting คือ สามารถกำหนดนโยบาย Rate limiting สำหรับการป้องกัน APIs เพื่อบรรเทาการโจมตี DDoS ด้วยการกำหนดขีดจำกัดจำนวน Client Request บน API Gateway ในแต่ละบริการของ API ในช่วงเวลาหนึ่งๆ นั้น จะช่วยแก้ไขปัญหาในเรื่อง Lack of Resources and Rate Limiting (API14) ช่องโหว่ใน OWASP API Security Top 10 2019.
• Authentication and Authorization คือ กระบวนการระบุตัวตนและการให้สิทธิ์ โดยต้องตรวจสอบให้แน่ใจว่าเป็น ไคลเอนต์ที่มีสิทธิ์การเข้าถึงที่ถูกต้องเท่านั้น ที่สามารถใช้ API ได้ กลไกหนึ่งที่ใช้คือ Claims ใน JSON Web Tokens (JWTs). จะช่วยแก้ไขปัญหาช่องโหว่ได้ 3 เรื่องใน OWASP API Security Top 10 2019.: Broken Object Level Authorization (API1), Broken User Authentication (API2), และ Broken Function Level Authorization (API5).

Advanced Security สำหรับ API Management

ตอนนี้ NGINX Controller API Management Module ได้เพิ่มความสามารถในส่วนของ API Security เพื่อป้องกัน APIs Endpoint ให้กับบริการของ Modern Application ได้แบบง่ายๆ และมีความปลอดภัยสูง

Distributed API Security in Any Environment

ด้วยความสามารถของ NGINX Controller App Security เราสามารถติดตั้ง Web Application Firewall (WAF) ในการป้องกัน APIs Endpoint แบบ Multi-Cloud ได้ง่าย ด้วยการเปิดการใช้งานความปลอดภัยบน NGINX API Gateway ที่สามารถติดตั้งได้บนระบบ Public Cloud, Private Cloud, Bare-metal, VMs หรือ Containers.

โดยปกติแล้วในส่วนของ Web Application Firewall (WAF) กับ API Gateway จะถูกติดตั้งแยกกัน เลยทำให้เกิดความซับซ้อน (Complexity) และทำให้แอปพลิเคชันเกิดช้าหรือหน่วง (Latency) ซึ่งในกรณีของ NGINX Controller API Management สามารถใช้งาน Web Application Firewall (WAF) เพื่อทำ API Security ได้สำหรับป้องกันการโจมตีในรูปแบบต่าง ๆ ที่เกิดขึ้น มีคุณสมบัติเรื่องของ Lightweight, Platform agnostic และ High Performance.

NGINX Controller App Security ถูกสร้างและพัฒนาจากทีม F5 Security Expertise โดยใส่ความสามารถในเรื่องการป้องกันการโจมตีต่าง ๆ ตามข้อมูลช่องโหว่ของ OWASP API Security Top 10 ร่วมถึงช่องโหว่ทั่วไปที่รู้จักเช่น SQL Injection, Remote Command Execution (RCE) เป็นต้น ทำการเพิ่มในส่วนของ การตรวจสอบ Malformed cookies, JSON, XML และตรวจสอบการอนุญาตให้ใช้งาน File Types ต่าง ๆ พร้อมการตรวจสอบ response status code พร้อมทั้งมีการตรวจสอบ Compliance ตาม HTTP RFCs ที่ถูกต้อง และการตรวจสอบเทคนิคการทำ Evasion เพื่อใช้ในการลบเลี่ยงการตรวจจับการโจมตี

Enhanced Visibility และ Analytics

Controller App Security สามารถดูค่า Metrics ที่หลากหลายและข้อมูลเชิงลึกเกี่ยวกับการโจมตีในรูปแบบที่แตกต่างกัน มีการแสดงถึงภัยคุกคามที่เกิดขึ้นบ่อย (Top WAF Threats) และเป้าหมายของ APIs  แสดง Top Signature สำหรับ False Positive Investigations, WAF outcome statistics, และ WAF Violation events ซึ่งจะช่วยให้เห็นในระดับตาม ช่องโหว่เรื่องของ Insufficient Logging & Monitoring vulnerability (API10) ของ OWASP API Security Top 10 2019.

ตัวอย่าง หน้าต่างของ NGINX Controller App Security สำหรับ Metrics ต่าง ๆ

• แสดงจำนวนประเภทการละเมิดความปลอดภัย เฉพาะช่วง 3 ชั่วโมงที่ผ่านมา เทียบกับช่วงเวลาเดียวกันในวันก่อนหน้า

• แสดงโหมดการบังคับนโนบายความปลอดภัย สำหรับ API Traffic ในช่วง 3 ชั่วโมงที่ผ่านมา

• แสดงประเภทการโจมตีสูงสุด ในช่วง 6 ชั่วโมงที่ผ่านมา

• แสดงการบันทึกเหตุการณ์ความปลอดภัย ในช่วง 30 นาทีที่ผ่านมา

ความยืดหยุ่น และการปรับแต่ง นโยบายความปลอดภัย (Fine-Tuned Policies)

NGINX Controller App Security ช่วยให้เกิดความยืดหยุ่น การปรับแต่งการตั้งค่าที่สามารถควบคุมนโยบายความปลอดภัยได้ง่าย โดยสามารถกำหนดโหมดของความปลอดภัยแบบ Blocking และ Monitoring-Only ได้ ซึ่งในการโหมด Monitoring-Only นั้นเป็นการเก็บข้อมูลการใช้งานของ Malicious Traffic เท่านั้นแต่ยังคงส่งข้อมูลต่อไปให้กับ API Endpoint เช่นเดิม และยังสามารถทำการ Disable ค่าเริ่มต้นของ Signature ได้เพื่อช่วยลด False Positives ได้ง่าย จากภาพที่แสดงด้านล่าง

จากหน้าต่างด้านล่างเป็นรายการของ Signatures ที่มีการ Blocking จากการร้องขอ API Calls เข้ามา ข้อมูลที่แสดงจะทำให้คุณสามารถใช้เป็นรายการหลักหรือความสำคัญของ Signature นำไปปรับแต่งการตั้งค่าเพื่อลดเรื่อง False Positives.

DevOps-Friendly API Security

          Controller App Security ช่วยให้คุณเพิ่มขีดความสามารถของ DevOps กำหนดการตั้งค่าต่าง ๆ ได้ด้วยตัวเองและลดขั้นตอนความยุ่งยากในการทำงานร่วมกันระหว่างทีม Security และ DevOps ตลอดจนรองรับการทำงานอัตโนมัติ (automation) ในการทำร่วมกันกับ CI/CD pipeline ได้ง่าย ส่งผลให้รูปแบบการพัฒนาแอบพลิเคชันสมัยใหม่นั้นมีการเพิ่มความปลอดภัยเข้าไปอยู่ใน Software Development Life Cycle (SDLC) ได้สมบูรณ์แบบ

ศึกษาข้อมูลเพิ่มเติม

https://www.nginx.com/blog/fortifying-apis-with-advanced-security/

https://www.nginx.com/products/nginx-controller/api-management/

https://www.nginx.com/products/nginx-app-protect/

สอบถามข้อมูลเกี่ยวกับผลิตภัณฑ์ F5 ได้ที่วีเอสที อีซีเอส (ประเทศไทย) โทร. 0-2032-9999 อีเมล : This email address is being protected from spambots. You need JavaScript enabled to view it.

Full Proxy – Overview of the F5 Standard Virtual Server

สวัสดีครับ บทความวันนี้อยากจะให้ท่านผู้อ่านมาทำความเข้าใจกับ F5 Virtual Server ในแบบ Standard Virtual Server Type ฟังแล้วท่านผู้อ่านอาจจะยังไม่เข้าใจว่าคืออะไร แต่ถ้าท่านใดเคยมีโอกาส Configures F5 Load Balance แล้ว คงพอจะนึกออกว่านี่คือ Default Type ของการสร้าง Virtual Server สำหรับงาน Load Balance นั้นเองครับ

สรุปโดยให้เข้าใจง่ายๆ ว่า Virtual Server หรือ Virtual IP (VIP) คืออะไรกันนะครับ

Virtual Server เป็นส่วนนึงของการจัดการการรับส่งข้อมูลบนระบบ Load Balance ที่แสดงตัวด้วยที่อยู่ของ Virtual IP Address และกำลังให้บริการอยู่ เช่น 192.168.20.10:80 เมื่อ Client ส่งทราฟฟิกของแอปพลิเคชันไปยัง Virtual Server ระบบ Load Balance จะรับฟังการส่งข้อมูลนั้นและกำหนดทิศทางการรับส่งข้อมูลไปยัง Real Server ตามการกำหนดค่าบน Virtual Server นั่นเอง

ดังนั้นค่าพื้นฐาน (Standard) จึงมีการกำหนดค่าเริ่มต้น (Default)

สำหรับการรับส่งข้อมูลผ่าน Load Balance Standard Virtual Server มีการตั้งค่าที่ช่วยให้คุณสามารถปรับแต่งการจราจรที่ Virtual Server ตามกระบวนการตัวอย่างเช่นคุณสามารถระบุโปรโตคอลที่เฉพาะเจาะจงเช่น TCP, UDP, Stream Control Transmission Protocol (SCTP)  หรือแม้แต่โปรโตคอลอื่นๆ นอกจากนี้คุณสามารถปรับแต่งวิธีการที่ระบบจัดการกับประเภทต่างๆของการจราจรได้ โดยกำหนดโปรไฟล์ไปยัง Standard Virtual Server ตัวอย่างเช่นการกำหนดค่าของการสามารถบีบอัด (Compression) HTTP ของข้อมูลผ่านระบบ หรือถอดรหัสและเข้ารหัสการเชื่อมต่อ SSL (SSL Decryption และ SSL Encryption) และสามารถตรวจสอบใบรับรอง SSL ว่ามีความถูกต้องหรือไม่

สำหรับแต่ละประเภทของการจราจรอื่นๆ (Protocol Profile) เช่น TCP, UDP, HTTP, HTTPS, SSL, SIP,SMTP, Stream, DNS, Radius, และ FTP นอกจากนี้ คุณยังสามารถกำหนดโปรไฟล์ที่กำหนดขึ้นเองได้

เมื่อคุณสร้าง Standard Virtual Server คุณสามารถกำหนด Specific Pool (Member of Real Server for Load Balance) หรือทำการ Load Balance หลายๆ Pools โดยเมื่อคุณต้องการส่ง Traffic ไปยังหลายๆทาง ที่มาจาก Virtual Server เดียวกัน นอกจากนี้คุณยังสามารถปรับแต่งคุณสมบัติทั่วไปของโปรไฟล์ความปลอดภัยบนเครือข่าย (Secure Network Address Translate – SNAT) และทรัพยากรอื่นๆเช่น iRule, Session Persistence, Port Translate, Address Translate หรือ Connection Limit เป็นต้น

สำหรับข้อมูลเพิ่มเติม แนะนำให้เข้าไปดูการกำหนดค่าในแต่ละส่วนของ Standard Virtual Server ได้ที่ Link นี้ครับ

https://support.f5.com/csp/article/K93017176

นอกจากการ Configuration ของ Standard Virtual Server ผมอยากพาท่านผู้อ่านมาเข้าใจหลักการทำงานของ Flow ของ TCP Connection บน Virtual Server Type นี้ เพราะมีรายละเอียดที่น่าสนใจอยู่ในนั้นครับ

ขอเกริ่นให้เข้าใจก่อนนะครับว่า ระบบของ F5 จะเรียกว่า TMOS ซึ่งจริงๆ แล้ว TMOS จะทำงานเป็นแบบ Full Proxy Architecture (การรวมกันของ Reverse Proxy และ Forward Proxy เข้าด้วยกัน) ซึ่งในการทำงานของ Virtual Server นี้นะครับ จะทำงานบน TCP Connection (TCP Profile) บน F5 Load Balance ซึ่งบน Virtual Server Type นี้จะบังคับให้เราเลือกว่าต้องการทำงานบน TCP, UDP หรือ All Protocol ก่อนครับ อย่าลืมเลือกให้ถูกต้องตามการใช้งานด้วยนะครับ

มาดูตัวอย่างการทำงานของ TCP บน Standard Virtual Server กันครับ

Standard virtual server with a TCP profile

ลักษณะการตั้งค่าการเชื่อมต่อ TCP สำหรับ Standard Virtual Server นี้ทำงานโดยเริ่มต้นด้วย Three-way TCP handshake จะเกิดขึ้นที่ฝั่งไคลเอ็นต์ที่ร้องของการเชื่อมต่อก่อนมาที่ระบบ F5 LTM หลังจากนั้นจะเริ่มต้น Three-way TCP handshake ที่ฝั่งเซิร์ฟเวอร์

Standard Virtual Server จะมีกระบวนการเชื่อมต่อ Connection ด้วย Full Proxy Architecture ตาม TCP Flow Diagram ด้านล่างนี้ครับ

Standard virtual server with TCP Profile and Layer 7 functionality

ถ้าเกิดว่า Standard Virtual Server ทำงานด้วย Layer7 function หรือการ Enable L7 Profile ไว้บน Virtual Server เช่น HTTP Profile ซึ่ง Client จะต้องส่ง Three-way TCP handshake และ data packet อย่างน้อย 1 packet มาก่อน และ F5 Load Balance จะเปิด Connection ด้วย Three-way TCP handshake และส่ง Packet ไปยัง Server เพื่อทำความเข้าใจมากขึ้น สามารถดูได้จากรูปด้านล่างครับ

จะเห็นได้ครับว่า F5 Standard Virtual Server เป็นการทำงานแบบ Full Proxy โดยแท้จริง คือการกำหนดการเปิด Connection ด้วย Three-way TCP handshake ที่ฝั่งของ Client ก่อนเสมอ ถึงจะเปิด Connection ที่ Server และส่ง Packet ไปให้ครับ

ซึ่งการทำงานในลักษณะนี้จะมีประโยชน์เป็นอย่างมากต่อสุขภาพของ Application Server ซึ่งจะเป็นผลดีต่อ Application Server ที่ให้บริการ เพราะ F5 จะไม่ยอมส่ง TCP Connection (TCP SYN) ไปยัง Server เลยถ้ากระบวนการของ Client ที่ร้องขอมา เปิด TCP Connection ไม่ถูกต้อง เช่น TCP SYN Flood รวมถึงถ้าใช้งานบน SSL Protocol (require secure renegotiation of SSL connections) ก็ยิ่งทำให้เรามันใจได้ว่า SSL ที่กำลังเข้ามาต้องถูกต้องก่อนที่จะ Establishing SSL Connection เสมอเช่นกันครับ

และถ้ามีการใช้งาน HTTP Protocol ก็สามารถกำหนดการตั้งค่าได้บน HTTP Service ได้เช่นการทำ HTTP Rewrite, Replace, Response, Redirect ให้เราสามารถปรับแต่งการทำงานได้ง่ายและยืดหยุ่นต่อการทำงานเป็นอย่างมากครับ

เป็นอย่างไรบ้างครับ บทความนี้พอจะเป็นแนวทางในท่านผู้อ่านที่กำลังสนใจ ได้มีความเข้าใจมากขึ้น และสามารถนำไปใช้งาน หรือกำหนดการตั้งค่า Standard Virtual Server ให้มีประสิทธิภาพสูงขึ้น ผมหวังว่าบทความนี้จะนำมาซึ่งความเข้าใจ ความรู้ในส่วนการทำงานของ F5 Load Balance ให้แก่ท่านผู้อ่านไม่มากก็น้อยนะครับ

ขอบคุณครับ

สอบถามข้อมูลเกี่ยวกับผลิตภัณฑ์ F5 ได้ที่วีเอสที อีซีเอส (ประเทศไทย) โทร. 0-2032-9999 อีเมล This email address is being protected from spambots. You need JavaScript enabled to view it.