ฉันจะกีดกันการแบ่งปันคีย์ API ภายในภายใน บริษัท ได้อย่างไร

37

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

เรากระตือรือร้นที่จะระบุว่าแอปพลิเคชันใดกำลังส่งคำขอใดเพื่อให้เราสามารถระบุรูปแบบการใช้งานและผู้พัฒนาที่รับผิดชอบ (เพื่อหลีกเลี่ยงข้อสงสัยการตรวจสอบผู้ใช้จะได้รับการจัดการแยกต่างหาก)

ทางออกของเราคือต้องใช้คีย์ API หนึ่งแอปพลิเคชัน - จากนั้นเรามีรายละเอียดการติดต่อสำหรับทีมพัฒนา

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

เราจะสร้างแรงจูงใจให้นักพัฒนาไม่ให้แบ่งปันคีย์ API ภายในได้อย่างไร

api enterprise-development

— Oli
แหล่งที่มา

5

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

— Giacomo Alzetta

3

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

— Sulthan

คุณคิดว่าจะต้องลงทะเบียนเมื่อแอปพลิเคชั่นเริ่มขึ้นครั้งแรกหรือไม่? มันสามารถแสดงหน้าจอสแปลชเพื่อขอรายละเอียดการติดต่อของผู้ใช้ (หรือข้อมูลอะไรก็ตามที่คุณต้องการ) จากนั้นออกคีย์ API ทันที

— John Wu

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

— Blerg

อยากรู้อยากเห็นฉันไม่เห็นคำว่า "การหมุน" (เช่นในการหมุนปุ่ม - การหมดอายุ / การหมุนหนังสือรับรอง) ที่ใดก็ได้ในหน้านี้ในขณะนี้ เมื่อใครบางคนได้รับกุญแจมันจะมีอายุการใช้งาน จำกัด หลังจากนั้นมันจะต้องถูกหมุนออกจากการใช้งานและแทนที่ด้วยรหัสใหม่หรือไม่? ถ้าไม่ทำไมไม่

— Michael - sqlbot

76

ในการแบ่งปันคีย์เหล่านั้นระหว่างทีมทีมต้องพูดคุยกันตกลงแบ่งปันจากนั้นแบ่งปัน ต้องใช้เวลา ดังนั้นหากทีมสามารถขอคีย์ API จากคุณได้อย่างรวดเร็วและง่ายดายยิ่งขึ้นไม่มีแรงจูงใจในการแบ่งปัน

และวิธีที่ง่ายที่สุดสำหรับพวกเขาที่จะขอกุญแจเหล่านั้นก็คือให้คุณจองล่วงหน้า สมมติว่าคุณรู้ว่าทีมอื่น ๆ ทั้งหมดที่จะต้องใช้คีย์ API สร้างพวกเขาและแบ่งปันพวกเขาก่อนที่จะให้บริการแก่พวกเขา

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

— เดวิดอาร์โน
แหล่งที่มา

2

Re: การแบ่งปันในโลกอุดมคติคุณพูดถูก แต่คุณคิดว่าพวกเขามีข้อมูลที่สมบูรณ์แบบ (แม้ว่าฉันสามารถช่วยได้โดยสั่งให้พวกเขาไปที่เอกสารจากสคีมารากของจุดสิ้นสุดและข้อผิดพลาดใด ๆ ) และการจัดการสหกรณ์และ ไม่ใช่ความจริงที่พวกเขาอาจมีคือจุดสิ้นสุดและคัดลอกรหัสจากทีมอื่นซึ่งผู้จัดการอาวุโสส่งต่อไป

— Oli

3

Re: การจองล่วงหน้าคุณถูกต้องอย่างแน่นอนเราควรสร้างและส่งกุญแจให้กับผู้ที่สนใจอย่างจริงจัง สิ่งที่ฉันไม่ได้กล่าวถึงคือแอพบางตัวใช้เฟรมเวิร์ก / อินเตอร์เฟสร่วมกันและบางทีเราสามารถฉีดหรือบังคับใช้คีย์เฉพาะในเลเยอร์นั้นแบบกึ่งอัตโนมัติ แต่อาจใช้กับแอพทั้งหมดไม่ได้

— Oli

1

@Ewan หากคุณเพียงแค่ปิดการเข้าถึงคีย์ที่กำหนดผู้ใช้ทั้งหมดจะวิ่งไปหาคุณโดยไม่จำเป็นต้องไล่ล่าพวกเขา และจากนั้นคุณสามารถมอบกุญแจที่เป็นเอกลักษณ์ให้พวกเขาได้ :)

— Alexei Levenkov

15

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

— candied_orange

1

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

— Robin Bennett

20

คำตอบที่ดีอยู่แล้วฉันแค่คิดถึงแนวทางที่แตกต่างซึ่งอาจจะใช่หรือไม่ใช่สำหรับคุณ

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

— Martin Maat
แหล่งที่มา

นั่นจะทำให้ชีวิตค่อนข้างยากขึ้นหากความเป็นเจ้าของแอปพลิเคชันเปลี่ยนไปตัวอย่างเช่นเราสามารถอัปเดตรายละเอียดคีย์ API ที่เก็บไว้ที่จุดสิ้นสุดของเราได้ แต่ถ้าเรายอมรับข้อความแบบฟอร์มฟรีที่ต้องการให้แอปพลิเคชันเปลี่ยนรหัส

— Oli

1

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

— Martin Maat

3

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

— Ewan

1

หากองค์กรมีวิธีการทั่วไปในการควบคุมเวอร์ชันเช่นทุกคนเก็บรหัสไว้บนเซิร์ฟเวอร์ GitHub ขององค์กรให้แต่ละแอปส่ง URL ไปที่ repo และแฮชคอมมิชชันที่สร้างขึ้น แฮชการคอมมิชชันสามารถรวมอยู่ในรหัสเป็นส่วนหนึ่งของกระบวนการบิลด์ดังนั้นผู้พัฒนาจึงไม่จำเป็นต้องอัปเดตอะไรเลย การมี repo URL ช่วยให้คุณเห็นว่าใครเป็นเจ้าของและการรับภาระผูกพันที่เฉพาะเจาะจงจะช่วยให้คุณสังเกตเห็นความแตกต่างของพฤติกรรมระหว่างเวอร์ชัน

— คาเลบ

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

— Martin Maat

16

ในระยะสั้น:

ครั้งแรก: การอำนวยความสะดวกและผลประโยชน์; ถ้าจำเป็น: ความเสียดทานและตำรวจ

บางคำเพิ่มเติม

การอำนวยความสะดวก : ขั้นแรกทำให้เป็นเรื่องง่ายสำหรับทีมที่จะได้รับคีย์ API ใหม่ ตัวอย่างเช่นเพิ่มการเตือนในขั้นตอนขององค์กรสำหรับการเปิดตัวโครงการใหม่และให้บริการที่ใช้งานง่ายเพื่อขอคีย์ใหม่โดยไม่ต้องขอเหตุผล

ประโยชน์ที่ได้รับ : ทำให้การใช้คีย์ API ของตัวเองเป็นประโยชน์สำหรับทีมหรือเจ้าของผลิตภัณฑ์ ตัวอย่างเช่นเสนอความคิดเห็นเกี่ยวกับการใช้แอพตามคีย์นั้น

ความเสียดทาน : คุณสามารถสร้างแรงเสียดทานได้ตัวอย่างเช่นหากคีย์เชื่อมโยงกับโดเมนที่กำหนดโดยแอพ somme (เช่นปุ่มนำกลับมาใช้ใหม่ไม่จำเป็นต้องให้การเข้าถึงบริการที่ต้องการทั้งหมด)

การรักษา : ในที่สุดคุณอาจจำเป็นต้องคาดการณ์มาตรการการรักษาบางอย่าง ตัวอย่างเช่นคุณสามารถตรวจสอบการใช้งานฟังก์ชั่น API โดยคีย์ api และหลังจากเวลาที่กำหนดเพื่อสร้างพื้นฐานสอบถามรายละเอียดเกี่ยวกับการใช้ชิ้นส่วน API ซึ่งไม่ได้คาดหวังในมุมมองของพื้นฐาน หรือหากไม่เป็นจริงเพียงรวมอยู่ในรายการตรวจสอบโครงการขององค์กรการตรวจสอบว่ามีการใช้รหัสที่ถูกต้อง

หมายเหตุ : คุณอาจต้องชัดเจนมากเกี่ยวกับนโยบายคีย์ API ของคุณ:เวอร์ชันหลักใหม่จะต้องใช้คีย์ API ของตัวเองหรือไม่ เกิดอะไรขึ้นกับทางแยกหรือถ้าแอพแยกกัน เกิดอะไรขึ้นถ้าทีมอื่นอยู่ในความดูแล ฯลฯ ...

— Christophe
แหล่งที่มา

6

โดยทั่วไปวิธีที่ง่ายที่สุดในการทำให้นักพัฒนา "ทำในสิ่งที่ถูกต้อง" คือทำให้พวกเขาทำเช่นนั้นได้ง่าย

ด้วยเหตุนี้ฉันขอแนะนำให้สร้างคีย์ API ที่ออกหน้าเว็บ / ไซต์ ในรูปแบบที่ง่ายที่สุดอาจเป็นเพียงการเข้าสู่ระบบ (ผูกติดอยู่กับ AD / LDAP ขององค์กรของคุณ) และหน้าเว็บที่เพิ่งขอชื่อแอปพลิเคชันและคีย์

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

คุณสามารถทำสิ่งที่คล้ายกับระบบจองตั๋วได้ แต่ในตอนท้ายของวันมันง่ายมากสำหรับฉันที่จะคัดลอกและวางกุญแจจากแอปหนึ่งไปยังอีกแอปหนึ่งดังนั้นมันง่ายมากที่จะขอคีย์ใหม่เพื่อหลีกเลี่ยงความเสียหาย พฤติกรรม.

— DavidT
แหล่งที่มา

1

เป็นเชิงรุก.

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

ติดตามว่ามีการใช้คีย์ API ใดและยังไม่ได้ใช้ปุ่มไหน หาก Bob ส่งตั๋วในโครงการ แต่ไม่ได้ใช้คีย์ API ของเขาแสดงว่าเขาอาจยืมคนอื่นมา

ได้รับการสนับสนุนจากฝ่ายบริหาร อย่าเป็น Nosy Nancy ที่จะทำตามกฎเกณฑ์ที่ไม่สำคัญ การโน้มน้าวใจฝ่ายบริหารอย่างแท้จริงว่ามันเป็นเรื่องสำคัญ อย่าพยายามโน้มน้าวใจทุกคน

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

— คริสโตเฟอร์ตัวประกัน
แหล่งที่มา

1

เราจะสร้างแรงจูงใจให้นักพัฒนาไม่ให้แบ่งปันคีย์ API ภายในได้อย่างไร

สร้างคีย์เป็นผลมาจากการลงทะเบียนสมัครใช้บริการด้วยตนเอง
ต้องใช้จุดสัมผัสก่อนที่ปุ่มจะทำงาน
และขอให้พวกเขาไม่แบ่งปัน (สร้างเงื่อนไขการใช้บริการและ / หรือบอกพวกเขาว่าทำไมมันจะดีกว่าสำหรับพวกเขาที่จะไม่แบ่ง.)

นอกจากนี้คุณยังควรใช้การ จำกัด อัตรา สิ่งนี้อาจทำให้หมดกำลังใจในการแบ่งปันคีย์ ช่วยปกป้องระบบของคุณในระดับหนึ่งจากแอปพลิเคชันที่ไม่เหมาะสม (และสิ่งที่เป็นอันตรายอย่างจริงจัง) และช่วยให้มั่นใจว่าคุณจะได้รับการแจ้งเตือนก่อนการรับส่งข้อมูลที่เพิ่มขึ้นอย่างมาก (ให้เวลาคุณเพิ่มความสามารถฉันหวังว่า!)

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

— svidgen
แหล่งที่มา

0

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

สิ่งนี้จะช่วยให้คุณบอกได้ว่ามันเป็นอะไรบางอย่างในการผลิต, QA, หรือ dev และที่รุ่น / สร้างปัญหาเริ่มต้นขึ้น

— Miral
แหล่งที่มา

0

สิ่งแรกและดีที่สุดที่คุณสามารถทำได้คือการจัดรูปแบบแป้นเพื่อให้พวกเขามีชื่อแอปพลิเคชันในรูปแบบที่อ่านง่ายและไม่ทำงานหากคุณเปลี่ยน

หากเห็นได้ชัดเมื่อทีมใช้คีย์ผิดพวกเขาจะพยายามไม่ทำ

จากนั้นคีย์หมดอายุเป็นระยะ คุณควรทำสิ่งนี้ต่อไปและเมื่อรหัสใกล้หมดอายุคุณสามารถส่งรหัสใหม่ให้กับทีมที่เป็นเจ้าของได้ ทีมที่ใช้รหัสจะได้รับแรงบันดาลใจเพื่อให้แน่ใจว่าพวกเขาเป็นทีมที่เป็นเจ้าของเพื่อให้พวกเขาได้รับรหัสใหม่เมื่อหมดอายุ

— Matt Timmermans
แหล่งที่มา

1

ในทางปฏิบัติแม้ว่าการหมดอายุคีย์อาจเป็นอุปสรรคสำหรับแอปพลิเคชั่นที่นำมาใช้มากเกินไป - ฉันเห็นผู้จัดการพูดว่า "fuggetaboutit" เพราะมันจะเป็นปัญหาในภายหลัง

— davidbak