ลายเซ็นดิจิทัลบนคลาวด์

ในยุคที่ธุรกรรมดิจิทัลสนับสนุนการค้าทั่วโลก ลายเซ็นดิจิทัลบนคลาวด์ได้กลายเป็นรากฐานที่สำคัญของความปลอดภัยและการตรวจสอบสิทธิ์ที่ปรับขนาดได้ ลายเซ็นเหล่านี้ใช้ประโยชน์จากโครงสร้างพื้นฐานคีย์สาธารณะ (PKI) ที่โฮสต์บนคลาวด์เพื่อผูกข้อมูลประจำตัวกับเอกสารหรือสตรีมข้อมูล ทำให้มั่นใจถึงความถูกต้องโดยไม่จำเป็นต้องมีตัวตนทางกายภาพ ต่างจาก PKI แบบดั้งเดิมที่อยู่ในองค์กร รูปแบบคลาวด์จะกระจายการจัดการคีย์ไปยังโครงสร้างพื้นฐานระยะไกล ซึ่งให้ความยืดหยุ่น แต่ก็ก่อให้เกิดความท้าทายที่ไม่เหมือนใครในด้านการยึดเหนี่ยวความน่าเชื่อถือและประสิทธิภาพ บทความนี้จะวิเคราะห์พื้นฐานทางเทคนิค การจัดแนวทางกฎหมาย และความต้องการทางธุรกิจของลายเซ็นดิจิทัลบนคลาวด์ โดยเน้นย้ำถึงบทบาทในการสร้างระบบนิเวศดิจิทัลที่ตรวจสอบได้

ต้นกำเนิดทางเทคนิค

วิวัฒนาการของลายเซ็นดิจิทัลบนคลาวด์สามารถสืบย้อนไปถึงโปรโตคอลการเข้ารหัสพื้นฐาน ซึ่งแยกการสร้างลายเซ็นออกจากฮาร์ดแวร์ในองค์กร ปูทางไปสู่สถาปัตยกรรมแบบกระจาย ที่แกนหลักคือลายเซ็นดิจิทัลใช้การเข้ารหัสแบบอสมมาตร โดยที่คีย์ส่วนตัวจะลงนามในข้อมูล และคีย์สาธารณะที่เกี่ยวข้องจะตรวจสอบความถูกต้อง การใช้งานบนคลาวด์ขยายฟังก์ชันนี้โดยการเอาท์ซอร์สการจัดเก็บและการดำเนินการคีย์ไปยังผู้ให้บริการคลาวด์ที่ได้รับการรับรอง โดยมักจะใช้โมดูลความปลอดภัยของฮาร์ดแวร์ (HSM) ในสภาพแวดล้อมแบบผู้เช่าหลายราย

โปรโตคอลและ RFC

โปรโตคอลที่สำคัญที่สนับสนุนเทคโนโลยีนี้ ได้แก่ Cryptographic Message Syntax (CMS) ซึ่งได้รับการกำหนดมาตรฐานใน RFC 5652 CMS มีเฟรมเวิร์กที่ยืดหยุ่นสำหรับการห่อหุ้มข้อมูลที่ลงนาม รองรับลายเซ็นแบบแยกส่วน ซึ่งเหมาะสำหรับกรณีที่เอกสารได้รับการประมวลผลแบบอะซิงโครนัสในเวิร์กโฟลว์บนคลาวด์ ตัวอย่างเช่น RFC 5652 รองรับการห่อหุ้มแอตทริบิวต์ของผู้ลงนาม การประทับเวลา และข้อมูลการเพิกถอน ซึ่งมีความสำคัญต่อการตรวจสอบความถูกต้องในระยะยาวบนคลาวด์ การเสริมมาตรฐานนี้คือ RFC 3278 ซึ่งระบุอัลกอริทึม CMS รองรับ RSA และ Elliptic Curve Cryptography (ECC) สำหรับการลงนามที่มีประสิทธิภาพในเครือข่ายคลาวด์ที่มีแบนด์วิดท์จำกัด ตาม RFC 5480 ECC ช่วยลดค่าใช้จ่ายในการคำนวณ ทำให้เป็นตัวเลือกที่ต้องการสำหรับการลงนามบนคลาวด์ที่รวมเข้ากับมือถือหรือ Edge

RFC ที่สำคัญอีกฉบับคือ 4055 ซึ่งให้รายละเอียดเกี่ยวกับการใช้ระบบการเข้ารหัส RSA ใน CMS ทำให้มั่นใจได้ถึงการทำงานร่วมกันข้ามแพลตฟอร์มคลาวด์ RFC เหล่านี้แก้ไขปัญหาความต้องการเฉพาะของคลาวด์ เช่น การดูแลและการกู้คืนคีย์ ตัวอย่างเช่น ประเภทเนื้อหาข้อมูลที่ลงนามของ RFC 5652 รองรับผู้ลงนามหลายราย ส่งเสริมสภาพแวดล้อมคลาวด์แบบร่วมมือ อย่างไรก็ตาม การตรวจสอบเชิงวิเคราะห์เผยให้เห็นช่องโหว่ การพึ่งพา Transport Layer Security (TLS) สำหรับการถ่ายโอนคีย์ (RFC 8446) สันนิษฐานว่าปลายทางคลาวด์ไม่ถูกบุกรุก แต่การโจมตีแบบปฏิเสธการให้บริการแบบกระจายอาจขัดขวางการตรวจสอบความถูกต้องของลายเซ็น โปรโตคอลเช่น JSON Web Signature (JWS, RFC 7515) ทำให้คลาวด์ขนาดเครือข่ายมีความทันสมัยยิ่งขึ้น รองรับลายเซ็นน้ำหนักเบาใน RESTful API โดยไม่จำเป็นต้องมีค่าใช้จ่ายจำนวนมากของ CMS การทำให้เป็นอนุกรมแบบกะทัดรัดของ JWS เหมาะสำหรับสถาปัตยกรรมไมโครเซอร์วิส แต่การเข้ารหัส base64 อาจทำให้ปริมาณงานเพิ่มขึ้นในสถานการณ์ที่มีปริมาณมาก ซึ่งต้องใช้วิธีการแบบไฮบริดกับ CMS เพื่อให้เป็นไปตามข้อกำหนดด้านกฎระเบียบ

มาตรฐาน ISO และ ETSI

มาตรฐาน ISO มีโครงสร้างพื้นฐาน ISO/IEC 11889 กำหนด Trusted Platform Modules (TPM) ซึ่งมักจะจำลองเสมือนในคลาวด์เพื่อการสร้างคีย์ที่ปลอดภัย ที่ตรงกว่านั้นคือ ISO 32000-1 ระบุ PDF Advanced Electronic Signatures (PAdES) กำหนดโปรไฟล์การตรวจสอบความถูกต้องในระยะยาวที่รวมเข้ากับ Cloud PKI PAdES ช่วยให้มั่นใจได้ว่าลายเซ็นยังคงตรวจสอบได้หลังจากการย้ายข้อมูลไปยังคลาวด์ โดยฝังห่วงโซ่ใบรับรองและ CRL (Certificate Revocation List) ลงในเอกสารโดยตรง จากมุมมองเชิงวิเคราะห์ การเน้นย้ำถึงการประทับเวลาของมาตรฐาน (ผ่าน RFC 3161) ช่วยลดความคลาดเคลื่อนของนาฬิกาในการปรับใช้คลาวด์ทั่วโลก แต่ช่องว่างในการใช้งานโปรไฟล์ PAdES บางส่วนอาจนำไปสู่ความล้มเหลวในการทำงานร่วมกันข้ามผู้ให้บริการ

มาตรฐาน ETSI โดยเฉพาะอย่างยิ่ง EN 319 122-1 อธิบายขั้นตอนการสร้างและตรวจสอบลายเซ็นอิเล็กทรอนิกส์ ซึ่งปรับให้เหมาะกับบริการความน่าเชื่อถือบนคลาวด์ สิ่งนี้มาแทนที่ TS 101 733 (CAdES) รุ่นเก่า โดยแนะนำหน่วยงานประทับเวลาที่ผ่านการรับรองบนคลาวด์ (QTStAs) เพื่อให้มั่นใจถึงลายเซ็นที่ไม่สามารถปฏิเสธได้ ETSI TS 119 312 ระบุชุดการเข้ารหัสเพิ่มเติม โดยกำหนดให้คลาวด์คีย์ใช้ FIPS 140-2 Level 3 HSM ซึ่งจากมุมมองเชิงวิเคราะห์แล้ว สิ่งนี้สร้างสมดุลระหว่างความปลอดภัยและความสามารถในการปรับขนาด แต่หากผู้เช่าหลายรายเปิดเผยข้อมูลเมตา ความเสี่ยงก็จะถูกเปิดเผย ETSI EN 319 401 ปรับโปรไฟล์ใบรับรองให้เป็นมาตรฐาน ทำให้มั่นใจได้ว่าคีย์ที่ออกโดยคลาวด์เป็นไปตามข้อกำหนด Extended Key Usage (EKU) ของ X.509 v3 สำหรับการลงนาม มาตรฐานเหล่านี้ร่วมกันทำให้เกิดลายเซ็นคลาวด์ “ที่ผ่านการรับรอง” แต่ความเข้มงวดอาจขัดขวางนวัตกรรม ตัวอย่างเช่น การมุ่งเน้นของ ETSI ไปที่รายการความน่าเชื่อถือส่วนกลางของสหภาพยุโรปอาจทำให้การนำไปใช้ทั่วโลกแตกแยก ซึ่งจำเป็นต้องมีการเชื่อมโยงเชิงวิเคราะห์ผ่านระบบระบุตัวตนแบบรวมศูนย์ เช่น SAML 2.0

โดยสรุป ต้นกำเนิดทางเทคนิคนี้เผยให้เห็นภูมิทัศน์ที่เติบโตเต็มที่แต่มีการพัฒนาอย่างต่อเนื่อง: โปรโตคอลและมาตรฐานให้ความแข็งแกร่ง แต่พลวัตของคลาวด์ต้องการการปรับตัวอย่างต่อเนื่องเพื่อรับมือกับภัยคุกคามควอนตัมและโมเดล Zero Trust

การทำแผนที่ทางกฎหมาย

ลายเซ็นดิจิทัลบนคลาวด์จะต้องนำทางกรอบกฎหมายที่ปะติดปะต่อกันเพื่อให้สามารถบังคับใช้ได้ โดยเฉพาะอย่างยิ่งในการรับรองความสมบูรณ์ของข้อมูลและการไม่สามารถปฏิเสธได้ ความสมบูรณ์รับประกันว่าเนื้อหาของลายเซ็นจะไม่ถูกเปลี่ยนแปลง ในขณะที่การไม่สามารถปฏิเสธได้จะป้องกันไม่ให้ผู้ลงนามปฏิเสธการกระทำของตน ซึ่งขยายใหญ่ขึ้นในสภาพแวดล้อมคลาวด์ผ่านการตรวจสอบย้อนกลับและบัญชีแยกประเภทที่ไม่เปลี่ยนรูป

กรอบ eIDAS

กฎระเบียบ eIDAS (910/2014) ของสหภาพยุโรปสร้างแบบจำลองความน่าเชื่อถือแบบแบ่งชั้นสำหรับลายเซ็นอิเล็กทรอนิกส์ โดยรูปแบบที่ใช้คลาวด์จะสอดคล้องกับลายเซ็นอิเล็กทรอนิกส์อย่างง่าย (SES), ลายเซ็นอิเล็กทรอนิกส์ขั้นสูง (AES) และลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง (QES) QES เป็นมาตรฐานทองคำ โดยกำหนดให้อุปกรณ์สร้างลายเซ็นที่ผ่านการรับรอง (QSCD) ซึ่งมักจะถูกนำไปใช้เป็น HSM บนคลาวด์ที่ได้รับการรับรองผ่าน ETSI EN 419 241-2 จากมุมมองเชิงวิเคราะห์ eIDAS กำหนดให้หน่วยงานประเมินความสอดคล้อง (CAB) ตรวจสอบผู้ให้บริการคลาวด์ รับรองความสมบูรณ์ผ่านการผูกมัดการเข้ารหัส และบรรลุการไม่สามารถปฏิเสธได้ผ่านใบรับรองที่ผ่านการรับรองที่ออกโดยผู้ให้บริการความน่าเชื่อถือ (TSP) มาตรา 32 กำหนดให้ QES มีความเท่าเทียมกับลายเซ็นที่เขียนด้วยลายมือ ลดข้อพิพาทในการพาณิชย์อิเล็กทรอนิกส์ข้ามพรมแดน

อย่างไรก็ตาม ความท้าทายของคลาวด์เกิดขึ้น: การพึ่งพาโครงการระบุตัวตนทางอิเล็กทรอนิกส์ที่แจ้ง (eIDs) ของ eIDAS สำหรับการพิสูจน์ตัวตนอาจใช้ไม่ได้ในคลาวด์แบบกระจายอำนาจ ซึ่งนามแฝงขัดแย้งกับระดับการรับประกันของมาตรา 24 การไม่สามารถปฏิเสธได้ได้รับการเสริมความแข็งแกร่งโดยการประทับเวลาและการบันทึกที่บังคับใช้ แต่ช่องว่างเชิงวิเคราะห์ยังคงอยู่ ปัญหาอธิปไตยของข้อมูลภายใต้ GDPR (มาตรา 44) อาจทำให้ลายเซ็นเป็นโมฆะหากคีย์อยู่ในคลาวด์ที่ไม่ใช่ของสหภาพยุโรป ซึ่งกระตุ้นให้ใช้โมเดลไฮบริดในองค์กร/คลาวด์สำหรับแอปพลิเคชันที่มีความเสี่ยงสูง

ESIGN และ UETA ของสหรัฐอเมริกา

ในสหรัฐอเมริกา พระราชบัญญัติ ESIGN (2000) และกฎหมายธุรกรรมทางอิเล็กทรอนิกส์ที่เป็นเอกภาพ (UETA ซึ่งนำมาใช้โดย 49 รัฐ) ให้ความเท่าเทียมกันของบันทึกและลายเซ็นอิเล็กทรอนิกส์ในระดับรัฐบาลกลางและระดับรัฐ มาตรา 101(a)(3) ของ ESIGN ถือว่าลายเซ็นดิจิทัลมีผลผูกพันทางกฎหมายหากพิสูจน์เจตนาและความยินยอม การใช้งานบนคลาวด์เป็นไปตามข้อกำหนดนี้ผ่านไบโอเมตริกซ์หรือการรับรองความถูกต้องแบบหลายปัจจัยในระหว่างการลงนาม ความสมบูรณ์ได้รับการกำหนดไว้ในมาตรา 106 โดยกำหนดให้บันทึกมีความถูกต้องและไม่เปลี่ยนแปลง Cloud PKI บรรลุสิ่งนี้ผ่านการตรวจสอบตามแฮชและความไม่เปลี่ยนรูปที่คล้ายกับบล็อกเชน

UETA สะท้อนเนื้อหานี้ โดยเน้นที่การระบุแหล่งที่มาในมาตรา 9 การไม่สามารถปฏิเสธได้ทำได้โดยการเชื่อมโยงผู้ลงนามกับลายเซ็นอิเล็กทรอนิกส์ที่เชื่อถือได้ของบันทึก จากมุมมองเชิงวิเคราะห์ กรอบทั้งสองนี้เป็นกลางทางเทคโนโลยี โดยสนับสนุนความสามารถในการปรับขนาดของคลาวด์ ตัวอย่างเช่น ข้อกำหนดความยินยอมของผู้บริโภคของ ESIGN (มาตรา 101©) ทำให้ลายเซ็น B2C ในแพลตฟอร์ม SaaS เป็นไปอย่างราบรื่น อย่างไรก็ตาม พวกเขาขาดระดับที่ผ่านการรับรองของ eIDAS ซึ่งเปิดเผยความเสี่ยง: หากไม่มีการตรวจสอบที่บังคับใช้ การรั่วไหลของคลาวด์อาจบ่อนทำลายการอ้างสิทธิ์ในการไม่สามารถปฏิเสธได้ ดังที่เห็นได้จากข้อพิพาทสมมติเกี่ยวกับการรั่วไหลของคีย์ การตีความกฎหมายเหล่านี้โดยศาลเป็นไปอย่างกว้างขวาง แต่แบบอย่างเชิงวิเคราะห์ (เช่น Shady Grove Orthopedic Assocs. v. Allstate Ins. Co.) เน้นย้ำถึงความต้องการมาตรฐานหลักฐาน ซึ่งกระตุ้นให้ผู้ให้บริการคลาวด์เปลี่ยนไปใช้การปฏิบัติตาม SOC 2 เพื่อเสริมสร้างความสามารถในการปกป้องทางกฎหมาย

การแมปข้ามเขตอำนาจศาลเผยให้เห็นการทำงานร่วมกัน – eIDAS QES สามารถตอบสนอง ESIGN/UETA สำหรับธุรกรรมระหว่างสหรัฐฯ และสหภาพยุโรปได้ – แต่ความแตกต่างในด้านความรับผิดชอบ (เช่น ความรับผิดชอบของ TSP ของ eIDAS กับความเป็นอิสระของคู่สัญญาของ UETA) จำเป็นต้องมีข้อกำหนดตามสัญญาสำหรับบริการคลาวด์ ในท้ายที่สุด การแมปเหล่านี้จะแปลงการเข้ารหัสที่เป็นนามธรรมให้เป็นคำมั่นสัญญาที่ดำเนินการได้ แม้ว่ากฎหมายความเป็นส่วนตัวที่พัฒนาอยู่ตลอดเวลาจะเรียกร้องให้มีการปรับตัวอย่างระมัดระวัง

บริบททางธุรกิจ

ในขอบเขตทางธุรกิจ ลายเซ็นดิจิทัลบนคลาวด์ช่วยลดความเสี่ยงโดยการปรับปรุงขั้นตอนการทำงาน ลดการฉ้อโกง และรับประกันการปฏิบัติตามข้อกำหนด โดยเฉพาะอย่างยิ่งในการโต้ตอบระหว่างการเงินและรัฐบาลกับธุรกิจ (G2B) คุณค่าเชิงวิเคราะห์ของมันอยู่ที่ ROI ที่วัดปริมาณได้: ตามเกณฑ์มาตรฐานอุตสาหกรรม การอนุมัติที่รวดเร็วขึ้นสามารถลดต้นทุนการดำเนินงานได้มากถึง 80% ในขณะที่ความปลอดภัยแบบฝังตัวหลีกเลี่ยงการละเมิดมูลค่าหลายล้านดอลลาร์

การใช้งานในภาคการเงิน

สถาบันการเงินใช้ลายเซ็นบนคลาวด์สำหรับการอนุมัติสินเชื่อที่ปลอดภัย การชำระบัญชีการค้า และการยื่นเอกสารกำกับดูแล ซึ่งสอดคล้องกับการมอบอำนาจของ Basel III และ Dodd-Frank ในการซื้อขายอนุพันธ์ ลายเซ็นสัญญาอัจฉริยะที่สอดคล้องกับ CMS ช่วยให้มั่นใจถึงการปฏิเสธไม่ได้ ลดความเสี่ยงของคู่สัญญาในตลาดที่มีความผันผวน จากมุมมองเชิงวิเคราะห์ ความยืดหยุ่นของ Cloud PKI รองรับลายเซ็นความถี่สูง – ตัวอย่างเช่น การประมวลผลการอนุมัติหลายพันรายการต่อวัน – เหนือกว่าระบบเดิม การลดความเสี่ยงเห็นได้ชัดในการป้องกันการฉ้อโกง: การตรวจสอบความสมบูรณ์ผ่าน RFC 5652 ขัดขวางการปลอมแปลงการโอนเงินทางอิเล็กทรอนิกส์ และบันทึกการปฏิเสธไม่ได้ช่วยในการตรวจสอบทางนิติเวชภายใต้มาตรา 404 ของ SOX

ความท้าทายรวมถึงการบูรณาการกับระบบธนาคารหลักเดิม อย่างไรก็ตาม API เช่น มาตรฐาน Open Banking ช่วยอำนวยความสะดวกในเรื่องนี้ โดยลดเวลาการชำระบัญชีจากหลายวันเหลือเพียงไม่กี่นาที ในการจัดการการลงทุน ลายเซ็นบนคลาวด์ช่วยให้สามารถส่งมอบหนังสือชี้ชวนทางอิเล็กทรอนิกส์ที่สอดคล้องกับ SEC Rule 498A ลดต้นทุนการพิมพ์และผลกระทบต่อสิ่งแวดล้อม อย่างไรก็ตาม การตรวจสอบเชิงวิเคราะห์เน้นย้ำถึงความเสี่ยงที่ซ่อนอยู่: การพึ่งพาคลาวด์ของบุคคลที่สามมากเกินไปอาจขยายภัยคุกคามที่เป็นระบบ เนื่องจากผู้ให้บริการรายเดียวหยุดชะงักจะรบกวนการเงินทั่วโลก กลยุทธ์การลดผลกระทบเกี่ยวข้องกับการกระจาย TSP และสถาปัตยกรรม Zero Trust เพื่อให้มั่นใจถึงความยืดหยุ่น

การลดความเสี่ยง G2B

ธุรกรรม G2B เช่น การประกวดราคาจัดซื้อและการยื่นภาษี ได้รับประโยชน์จากการตรวจสอบได้ของลายเซ็นบนคลาวด์ ซึ่งสอดคล้องกับกรอบการทำงาน เช่น Federal Acquisition Regulation (FAR) ของสหรัฐอเมริกา หรือ Single Digital Gateway ของสหภาพยุโรป รัฐบาลใช้สิ่งเหล่านี้สำหรับใบแจ้งหนี้อิเล็กทรอนิกส์ โดยที่ PAdES รับประกันความสมบูรณ์ของเอกสารในห่วงโซ่อุปทาน ลดการฉ้อโกงในการจัดซื้อจัดจ้างซึ่งคาดว่าจะอยู่ที่ 5-10% ของมูลค่าสัญญา การปฏิเสธไม่ได้ผ่านการประทับเวลาที่มีคุณสมบัติเหมาะสม ป้องกันการปฏิเสธการจัดการการประมูล ส่งเสริมความโปร่งใสในการใช้จ่ายสาธารณะ

จากมุมมองเชิงวิเคราะห์ ความสามารถในการปรับขนาดของคลาวด์รับมือกับปริมาณสูงสุดของ G2B – ตัวอย่างเช่น ฤดูกาลภาษี – ในขณะที่ลดภาระด้านการบริหาร เวิร์กโฟลว์ดิจิทัลภายใต้ UETA เร่งการอนุมัติ เพิ่มการมีส่วนร่วมของ SME การลดความเสี่ยงขยายไปถึงการปฏิบัติตามข้อกำหนด: ลายเซ็นฝังสถานะการเพิกถอน ซึ่งช่วยในการตรวจสอบการฟอกเงิน (AML) ที่แนะนำโดย FATF ในการจ่ายเงินช่วยเหลือระหว่างประเทศ คลาวด์ที่สอดคล้องกับ eIDAS ช่วยให้มั่นใจได้ถึงการติดตามเงินทุนที่ตรวจสอบได้ ป้องกันการทุจริต

อย่างไรก็ตาม อุปสรรคในการทำงานร่วมกันยังคงอยู่ มาตรฐานระดับชาติที่แตกต่างกันทำให้ระบบนิเวศ G2B แตกแยก ซึ่งต้องใช้ PKI ที่เป็นสหพันธ์ ผู้นำทางธุรกิจต้องชั่งน้ำหนักสิ่งเหล่านี้กับผลประโยชน์: การวิจัยของ Forrester ในปี 2023 คาดการณ์ว่าการแปลง G2B เป็นดิจิทัลจะช่วยประหยัดได้ 2 หมื่นล้านดอลลาร์ต่อปี ซึ่งเน้นย้ำถึงศักยภาพในการเปลี่ยนแปลงของลายเซ็นบนคลาวด์ ในเชิงกลยุทธ์ บริษัทที่นำเทคโนโลยีเหล่านี้มาใช้จะได้รับความได้เปรียบในการแข่งขันในภาคส่วนที่หลีกเลี่ยงความเสี่ยง โดยสร้างสมดุลระหว่างนวัตกรรมและการเสริมสร้างการป้องกัน

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