システム・アプリ関連紛争

Androidアプリの脆弱性に対する開発者の法的責任

弁護士・情報処理安全確保支援士 石田 優一

 

スマートフォンやタブレットの普及により,Androidアプリがビジネスでもプライベートでも身近な存在となっています。そのような中,社会問題になりつつあるのが,Androidアプリの脆弱性による情報漏えい事例です。

今回のコラムでは,SQLインジェクション攻撃に対するシステムの脆弱性が原因で情報漏えい事故が発生したことに対する開発者の法的責任が問題になった裁判例(東京地判平成26年1月23日)や,「Androidアプリのセキュア設計・セキュアコーディングガイド」等を踏まえ,Androidアプリの脆弱性に対して開発者がどのような法的責任を負うかについて考えたいと思います。

 


第1章 はじめに

 

スマートフォンやタブレットの普及により,Androidアプリは,ビジネスでもプライベートでも身近なものとなっています。

 

ビジネスでは,営業回りのタブレット利用が普及しつつあり,商品の紹介から契約まで,1台のタブレットで済ませられるようになっています。また,スケジュールや顧客情報の管理も,スマートフォンやタブレットを利用する人が増えています。様々な書類のペーパーレス化は,業務の効率化につながり,「働き方改革」時代において重要なツールとなっています。

 

プライベートでは,メール,SNS,買い物,家計管理,アルバムづくりから,健康管理まで,日常生活の様々な機会で活躍の場があります。

 

このように,Androidアプリは,私たちの生活やビジネスを豊かで便利なものにしています。

 

一方で,Androidアプリは,上記の例からも明らかなように,様々な個人情報を取り扱うことから,大切な個人情報を漏えいさせる「犯人」となってしまうことがあります。もちろん,脆弱性が全くないアプリであればそのようなことは起きませんが,脆弱性ゼロのアプリを開発することは決してたやすいことではありません。

 

もし,あなたの会社が開発したAndroidアプリが原因で大切な個人情報が漏えいして,損害賠償を求められた場合,請求者に言われるがままに応じざるを得ないのでしょうか。その答えはノーです。なぜなら,「脆弱性があること」と,「法的責任を負うこと」とは,決してイコールではないからです。

 

今回のコラムでは,Androidアプリの開発者に向けて,脆弱性による個人情報の漏えい事故が起きた場合の法的責任について検討したいと思います。

 

※このコラムでご紹介する内容は,あくまでも裁判例を参考にした執筆者の見解です。同様の見解が,実際の訴訟等において採用されることを保証するものではございませんので,あらかじめご留意ください。

 

Androidアプリの利用

 

第2章 システム・ソフトウェアの脆弱性に対する法的責任

1 脆弱性に対する法的責任とは

 

先ほども述べたように,「脆弱性があること」と,「法的責任を負うこと」は,イコールではありません。なぜなら,システム・ソフトウェアを開発するうえで,脆弱性をゼロにすることは,現実的ではないからです。

 

パソコンを使用しているとWindowsから定期的に更新を求められるように,たとえMicrosoft社が開発したソフトウェアでも脆弱性はあります。だからといって,Microsoft社が更新のたびに脆弱性に対する法的責任を問われることはありません。

 

また,システム開発紛争の裁判例を見ると,例えば,東京地判平成9年2月18日「ダイセーロジスティック事件」判決では,開発者は,たとえ納入したシステムにバグがあったとしても,直ちには責任を問われないことを前提とした判断がされています。同様の考え方は,脆弱性についても,(少なくとも軽微なものであれば)妥当します。

 

それでは,開発者が法的責任を負うのは,どのような場合でしょうか。

 

第1に,開発者とユーザーとの間の契約に法的責任についての定めがあれば,それに従うのが原則です。契約書の中に,「・・・場合は,・・・損害を賠償すべき責任を負う」という規定があれば,その要件に該当するかどうかが問題になります。

 

第2に,開発者とユーザーとの間の契約において,法的責任について特段の規定を設けていない場合には,民法の規定による責任を負います。

 

改正前民法では,売買契約において,売主が買主に引き渡した物に「隠れた瑕疵」があったときは,売主が買主に対して損害賠償責任を負うことが定められています(改正前民法570条)。また,請負契約において,請負人が完成させた(又は引き渡した)物に「瑕疵」があったときは,注文者は,請負人に対し,損害賠償を請求できることが定められています(改正前民法634条2項)。

 

「瑕疵」(かし)とは,「きず」という意味ですが,民法のいう「瑕疵」とはどのような意味かについて,学説の対立がありました。最近の学説では,物の性質が契約で合意された内容に適合していないことを「瑕疵」という考え方(契約責任説)が有力になっています。詳しくは,民法の債権各論・契約法に関する書籍をご参照ください。

 

このような学説の流れを受けて,2020年4月から施行予定の改正後民法では,「瑕疵」という用語が,「種類や品質に関して契約の内容に適合しない」(改正後民法566条,636条)と改められることになります。

 

以上のとおり,システム・ソフトウェアの脆弱性に対して開発者が法的責任を負うかどうかは,一般に,その脆弱性に対する対策を講じることが「契約上要求されていたかどうか」によって判断されます。

 

2 システムの脆弱性によるクレジットカード情報の漏えいに対する責任が問われた事例

(1) 事案の概要

 

システムの脆弱性を理由にシステム開発者の法的責任が問われた事件としてしばしば取り上げられるのが,東京地判平成26年1月23日(平成23年(ワ)第32060号)です。

 

この事件では,開発者が制作したウェブサイトに何者かが不正アクセスを行い,SQLインジェクション攻撃によってデータベースシステムのクレジット情報を不正取得されたことについて,開発者の法的責任が問われました。

 

今ではSQLを利用したシステムの開発に携わる多くの方がご存知のように,SQLインジェクションは有名な攻撃手法であり,バインド機構の使用やエスケープ処理によって対処すべきことは,専門家の中では広く知られています。この事件においては,バインド機構の使用やエスケープ処理による対処がされていなかったことが問題になりました。

 

また,データベースに保存されたクレジットカード情報について,暗号化して保存すべき義務があったかどうかについても,問題になりました。

 

この事件の判決では,開発者がバインド機構の使用やエスケープ処理による対処を怠っていたことについて法的責任を認めて,損害賠償の請求を認容しました。一方で,クレジットカード情報を暗号化して保存すべき義務等については,否定しました。

 

ここからは,2つのセキュリティ対策について判断が分かれた理由も踏まえながら,判決のポイントを詳しく説明します。

 

(2) 開発者はどのような義務を負っていたのか

 

この事件のケースでは,契約書で「(開発者)が委託業務に関連して,(開発者)又は(開発者)の技術者の故意又は過失により,(ユーザー)・・・に損害を及ぼした時」に,開発者が損害賠償責任を負うことは定められていましたが,セキュリティ対策について開発者がどのような義務を負うかについては契約書に明示されていませんでした

 

「過失」とは,(損害を生じさせる)結果が発生することについて予見することができた(予見可能性)にもかかわらず,結果の発生を回避するために必要とされる措置を講じなかったことをいうとされています。

 

つまり,(1) 開発者が要因となった脅威による情報漏えいを予見しておく義務(予見義務)があったか,(2) 予見すべき脅威による情報漏えいを回避するために,どのようなセキュリティ対策を講ずべき義務(結果回避義務)を負っていたかが,ポイントになります。

 

さて,ここで問題になるのが,開発者が負わなければならないこれらの義務の「レベル」です。開発者は,システムが被害を受ける可能性のある脅威をどこまで予見しなければならず,そして,その脅威を予防するためにどこまでの対策を講じなければならないのでしょうか。

 

極端な例でいえば,世界中の文献をくまなく調査して,被害につながりうる脅威をすべて予見し,世界最高水準のセキュリティ対策を講じなければならないとすれば,法的責任を負わない開発者はほぼ皆無となり,だれもシステム開発ができなくなるでしょう。一方で,レベルを一般人にまで下げてしまえば,SQLインジェクションも,DDoS攻撃も,「多くの一般人は知らないから対策を講じなくてよい」ことになってしまいます。

 

また,たとえ何らかの脅威によって不正アクセスを受けるおそれを予見したとしても,不正アクセスによる被害を防ぐためにありとあらゆる措置を講じなければならないとすれば,予算に見合わない莫大な開発コストを要してしまいます。

 

過失による損害に対して賠償責任を負うというのは,契約で定められた義務です。ですから,予見義務や結果回避義務を考えるうえでは,「契約者双方でどのような合意があったか」に基づき,高すぎず,かつ,低すぎない,適切なレベルを設定する必要があります。

 

この事件の判決は,「(契約締結)当時の技術水準に沿った(個人情報の漏えいを防ぐために必要な)セキュリティ対策を施したプログラムを提供することが黙示的に合意されていた」と認定しています。また,開発者がプログラムに関する専門的知見を活用した事業を展開していたことや,ユーザーがその専門的知見を信頼して契約を締結したと推認できることから,開発者に求められる注意義務の程度は比較的高度なものであると認定しています。

 

つまり,判決は,プロの技術者であれば持っていたであろう(比較的高度な)契約締結当時のレベルに判断基準を設定して,予見義務や結果回避義務を検討しているわけです。

 

(3) SQLインジェクション対策をすべき義務があったか

 

判決は,開発者が,契約当時,SQLインジェクション攻撃による情報漏えいを予見して,バインド機構の使用・エスケープ処理といったSQLインジェクション対策を講ずべき義務を負っていたことを認めています。

 

その理由として,契約時から約3年前に,経済産業省から,SQLインジェクション攻撃による被害が相次いでいるのでIPA(独立行政法人情報処理推進機構)の紹介するSQLインジェクション対策を重点的に実施することを求める旨の注意喚起があった点や,その翌年にIPAが出した文書に,SQLインジェクション対策としてバインド機構の使用・エスケープ処理等で対策をする必要がある旨が明示されていた点を挙げています。

 

経済産業省やIPAが,何年も前から,SQLインジェクション攻撃の危険性や,具体的なSQLインジェクション対策の必要性について積極的な呼びかけをしていた以上,プロの技術者であれば予見義務・結果回避義務を負うべきであると認定したわけです。

 

なお,判決では,開発者がSQLインジェクション対策を講じていなかったことについて,SQLインジェクション攻撃による情報漏えいのおそれを容易に予見できたことや,SQLインジェクション対策によって多大な労力や費用を要せずに情報漏えいを容易に回避できたことを理由に,重大な過失があったことまで認めています。

 

(4) クレジットカード情報を暗号化して保存すべき義務があったか

 

一方で,判決は,開発者が,データベースのクレジットカード情報を暗号化して保存すべき義務等を負っていたことについては,否定しています。

 

保存情報を暗号化すべき義務を否定する理由として,IPAが出した文書において,重要 なデータや個人情報の暗号化が「望ましい」と指摘されるにすぎない点や,同文書において,「データベース内のデータ全てに対して暗号化の処理を行うとサーバー自体の負荷になることがあるので,特定のカラムだけを暗号化するなどの考慮が必要である」と指摘されている点,暗号化の設定によって開発者の作業量や代金も増減する点等が挙げられています。

 

そして,契約で特別の合意をしていなければ,保存情報を暗号化すべき義務を負っていたとは認められないと判断しています。

 

3 まとめ

 

前述したように,システム・ソフトウェアの脆弱性に対して開発者が法的責任を負うかどうかは,その脆弱性に対する対策を講じることが「契約上要求されていたかどうか」によって判断されます。

 

先ほど取り上げた裁判例のケースでは,損害賠償責任に関する契約条項はありましたが,そこには,「故意又は過失により・・・損害を及ぼした時」としか定められていませんでした。このような契約条項がなかったとしても,開発者には,民法上の同様の責任が認められたであろうと考えられます。

 

裁判例は,開発者の法的責任を認めるべきかどうかを検討するうえで,経済産業省やIPAが公表する資料の記載内容を重視しています。これは,システム・ソフトウェア開発を行う事業者であれば,日頃から省庁やIPAといった公的機関等が公表するセキュリティ関連情報を収集し,それに応じた対策を講じておくことが,プロのレベルとして当然に求められるからであるといえます。

 

裏を返せば,ユーザーが開発者に対して,公的機関の資料にも必要な措置と明示されていないような高度なセキュリティ対策を求めるのであれば,具体的にどのような対策を開発者に求めるかについて,文書等で明示しておくべきという見方もできます。

 

また,セキュリティ対策が契約上要求されているかどうかを検討するうえでは,その対策を講じることによる労力・コストの負担や,処理能力の低下等の仕様への影響も考慮する必要があります。

 

さて,次章では,ここまで説明した内容を踏まえ,Androidアプリの開発者が法的責任を負わないために講ずべき脆弱性対策について検討したいと思います。

 

Androidアプリの利用

 

第3章 Androidアプリの脆弱性対策

1 どのような観点から検討すべきか

 

前章で説明したように,開発者がソフトウェアの脆弱性による情報漏えいに対する責任を負うのは,ユーザーとの契約に基づいて, (1)要因となった脅威によって情報漏えいが起きることを予見すべき義務(予見義務)を負い,かつ,(2)その脅威による情報漏えいを予防するために,原因となった脆弱性をなくすための対策を施すべき義務(結果回避義務)を負っていたといえる場合です。

 

そして,開発者がどのようなセキュリティ対策を講じなければならないについて,契約で特に定めていないときは,これらの義務を負うかどうかは,労力・コストの負担や,処理能力の低下等の仕様への影響も考慮しながら,公的機関が契約締結当時に提供していたセキュリティ対策情報等を参考に判断すべきです。

 

このような観点を踏まえて,ここからは,Androidアプリの開発者が,ユーザーとの間で,セキュリティ対策に関して契約で特に定めていないことを前提に,開発者が法的責任を負わないためにどのような脆弱性対策を講じなければならないかを検討します。

 

2 仮想事例を踏まえて

【仮想事例】

X社は,個人向けに化粧品を販売する事業を展開している。X社は,新たに,Webサイトに問い合わせのあった方の自宅をスタッフが訪問し,タブレットで商品紹介をしたうえで,その場で商品を気に入っていただいたときにはタブレットを使って商品購入契約を交わすことができるサービスを展開していた。

X社では,もともと各スタッフに業務用タブレットを貸与しており,アプリのダウンロードも含めて,その管理は各人に任せていた。コスト削減の観点から,上記サービスは,既存のタブレットに専用アプリをインストールする方法で実現することになった。

X社は,アプリ開発会社であるY社に専用アプリの制作を受注した。X社・Y社間で検討を重ね,スタッフがおすすめの商品を的確に紹介できるように,アプリに顧客情報を入力すると,過去に購入した商品やその効能,スタッフがこれまで聴き取った肌に関するお悩みが一覧表示される機能を設けることになった。また,顧客識別情報として,氏名,住所,電話番号,勤務先等を入力するようにした。

 

 

(1) アプリで取扱う情報の要保護性

 

このアプリのセキュリティ対策を検討するうえで重要なのは,取り扱う情報の要保護性,つまり,法的な観点からどの程度保護すべき必要性が認められるかです。

 

まず,顧客識別情報は,特定の個人を識別することができる情報ですので,「個人情報」(個人情報保護法2条1項1号)に該当します。また,過去に購入した商品や肌のお悩みに関する情報も,それ自体は個人情報ではありませんが,顧客識別情報と紐づけして取り扱われることで,個人情報の一部を構成するものといえます。以下,これらの情報を「顧客情報」として説明します。

 

さらに,顧客情報がデータベース化されることで,個々の顧客情報は「個人データ」(個人情報保護法2条6項)に該当することになります。

 

個人情報取扱事業者は,取り扱う個人データの漏えい,滅失又はき損の防止その他の個人データの安全管理のために必要かつ適切な措置(安全管理措置)を講じなければならないことが,個人情報保護法20条で義務付けられています。法律には,具体的に講ずべき措置について明記されていませんが,個人情報保護委員会が個人情報保護法ガイドラインを公表しており,その中で具体的に講ずべき具体的措置が示されています。

 

次に,顧客情報の内容を踏まえ,どの程度保護すべき必要性があるかについて検討します。ここで注目すべきなのは,顧客情報の中に,過去に使用した化粧品や肌のお悩みに関する情報が含まれている点です。顧客情報は,漏えいすることによって直ちに顧客に金銭的損害を与えるものではありません。しかし,顧客にとって,肌にどのような悩みを抱えているかは,あまり他人に知られたくない情報であるといえます。そうすると,顧客情報は,病歴や投薬に関する情報には及ばないとしても,プライバシーの観点から保護すべき必要性の高い情報であると考えられます。

 

この事例において,顧客情報の安全管理措置を負うのは,あくまでもX社であって,Y社ではありません。また,個人情報保護法は行政規制ですので,安全管理措置を講じなければ,直ちに損害賠償責任のような民事上の責任を負うわけではありません。

 

ただ,顧客情報が要保護性の比較的高い情報であることに鑑みると,アプリ開発者であるY社も個人情報保護法ガイドラインに沿ったセキュリティ対策を積極的に講ずべき義務を負い,そのような義務を怠った場合には民事上の責任を負うおそれがあると考えられます。

 

(2) 個人情報保護法ガイドライン

 

ガイドラインで示される具体的措置をこの事例に当てはめると,例えば,次のような技術的対策を講ずることが求められます。

※X社が中小規模事業者に該当しないことを想定しています。

 

・顧客情報を管理するデータベースに専用アプリ以外からアクセスできないように適切なアクセス制御をすること

・アプリをスタッフ以外の者が利用することができないように利用者の識別・認証を行うこと

・データベースへの不正アクセスを防止するための適切なネットワーク設計を行うこと

・アプリとデータベースサーバーとの通信の経路又は内容を暗号化すること

 

 

(3) Androidアプリのセキュア設計・セキュアコーディングガイド

 

Androidアプリを設計するうえで参考になるのが,一般財団法人日本スマートフォンセキュリティ協会(JSSEC)の公表する「Androidアプリのセキュア設計・セキュアコーディングガイド」(以下「JSSECガイド」といいます。)です。

 

JSSECガイドは,公的機関が公表する資料ではありません。ただ,「【注意喚起】HTTPSで通信するAndroidアプリの開発者はSSLサーバー証明書の検証処理の実装を」(2014年9月19日)というIPAのプレス発表資料では,SSLサーバー証明書を用いた検証の実装方法について,JSSECガイドを参照すべきことが示されています。このことから,IPAも,JSSECガイドを信頼のおける資料として位置づけているものと考えられます。

 

また,JSSECガイドは,Android OSのアップデートや最近の脆弱性情報を踏まえて定期的に改訂されていることや,開発者にとって比較的一般的な脆弱性対策が網羅的に示されていること,プログラムのサンプルが詳細に掲載されていて開発者にとって使いやすい資料であること,Androidアプリのセキュア設計を取り上げた公的資料はあまりないことを踏まえると,Androidアプリの脆弱性が問題になった場合に参照すべき重要な資料の1つであると考えられます。

 

(4) HTTPS通信の実装

 

データベースに専用アプリ以外からアクセスできないようにアクセス制御を行い,また,アプリとデータベースサーバーとの通信の経路又は内容を暗号化するためには,サーバーとアプリとの間のHTTPS通信を実装する必要があります。

 

HTTPS通信の実装方法は,JSSECガイドで詳述されていますので,それを参考に検討したいと思います。

 

この事例の場合,専ら社用タブレットと社内サーバーとの間の通信のみを実装するので,プライベート証明書によるHTTPS通信も選択し得ます。特に,プライベート証明書によるHTTPS通信を実装する場合には,JSSECガイドのサンプルやルールブックの説明を参考に,脆弱性のないセキュア設計に配慮する必要があります。また,サーバー証明書の検証時にSSLExceptionの例外処理がなされた場合には,情報セキュリティ担当者に連絡するように警告表示を行ったり,ログに例外処理がなされたことを記録したりする設計にし,また,HTTP通信に切り替えて通信を継続するような設計には絶対にしないように注意しなければなりません。

 

先ほど取り上げたIPAのプレス発表資料でも,HTTPS通信においてサーバー証明書の検証処理を適切に行われないことの危険性が指摘されており,その実装に不備があると,情報漏えいが発生した場合に開発者の法的責任を問われるおそれがあります。

 

(5) 利用者の識別認証機能の実装

 

スタッフ以外の者がアプリを利用することができないようにするためには,利用者の識別認証機能を実装する必要があります。

 

利用者のパスワード入力による識別認証を実装する場合,JSSECガイドでも示されているように,パスワードのマスク表示をデフォルトにすることや,パスワードを平文表示する前に注意を促す機能を設けること等が必要です。

 

このような対策を講ずる1番の意味は,ショルダーハッキング(画面を肩越しに覗き見られて情報を盗まれること)の予防です。ショルダーハッキングは,IPAの複数の公表資料において危険性が指摘されており,上記の対策をきちんと講じていないと,情報漏えいが発生した場合に開発者の法的責任を問われるおそれがあります。

 

3 その他のセキュア設計

(1) 適切なアクセス制限

 

IPAは,「IPAテクニカルウォッチ『Androidアプリの脆弱性』に関するレポート」(2012年6月13日)において,2012年5月時点でIPAに届け出られた脆弱性の約7割が,アクセス制限の不備であったと指摘しています。そして,脆弱性の例として,コンポーネントやファイルのアクセス制限の不備を挙げています。

 

また,コンポーネントやファイルのアクセス制限に対する対策については,JSSECガイドでも詳細に取り上げられています。

 

開発者が設計したアプリにアクセス制限の不備があり,アプリで取り扱う重要な情報が漏えいした場合,開発者が法的責任を問われるおそれがあります。

 

仮想事例でも検討したように,脆弱性対策をどこまで重点的に実施する必要性があるかを検討するうえでは,取り扱う情報の要保護性を考慮する必要があります。要保護性を検討するうえでは,情報漏えいによって生じうる財産的損害や,プライバシー侵害の程度等の事情を検討すべきです。

 

(2) コンポーネントのアクセス制限

 

JSSECガイドでは,コンポーネントの種類(Activity,Broadcast,Content Provider,Service)ごとに,適切なアクセス制限の実装方法について説明しています。

 

コンポーネントの種類によって実装方法に違いはありますが,基本的な考え方は,他のアプリと連携する必要性に応じて,適切な公開・非公開の設定を行うべきということです。

JSSECガイドでは,適切な公開・非公開の設定について,サンプルコードも含めて詳述されています。特に,特定のアプリとの間でのみデータのやり取りを行う仕様の場合,JSSECガイドの説明を参考に,適切な公開設定を行う必要があります。

 

(3) ファイルのアクセス制限

 

重要な情報を含むファイルについては,アプリディレクトリ内に作成し,かつ,プライベートモードに設定して他のアプリから利用できないようにすることが原則です。

 

JSSECガイドの説明を踏まえると,他のアプリとデータを共有する必要がある場合, Content Provider等を利用して適切なアクセス制限を行うべきです。実装方法については,JSSECガイドに掲載されています。

 

また,SDカードに重要な情報を保存することの危険性は,IPAのレポートやJSSECガイドにおいて指摘されています。SDカードに重要な情報を保存する設計は極力避け,どうしても必要がある場合には,適切な暗号化を行い,他のアプリから読み取られる危険性を予防すべきです。

 

4 まとめ

 

本章で取り上げたのは,開発者が対策を講じておかなければ法的責任を問われるおそれのあるケースの一例にすぎません。開発者は,IPAの注意喚起最新のJSSECガイドの内容を取り入れながら,適切な設計を行う必要があります。

 

第4章 おわりに

 

前章では,開発者とユーザーとの間でセキュリティ対策について特に合意していない場合に,開発者がどのようなセキュア設計を行わなければ法的責任を問われるおそれがあるか,という観点で検討しました。もっとも,法的責任を問われる範囲と問われない範囲の線引きというのは,なかなか難しいものです。実際の紛争では,責任の有無を巡って,開発者・ユーザーの対立が生じることが予想されます。なぜなら,「セキュア設計はこのレベルでしてください」という明確な基準はないからです。

 

開発者とユーザーとがいずれも事業者の場合は,セキュア設計についてもきちんと協議して合意しておくことが望ましいです。特に,秘密性の高い情報をアプリにおいて取り扱う場合には,セキュア設計について詳細な合意をしておくべきです。

 

第2章で述べたように,法的責任を問われる範囲と問われない範囲の線引きを決めるのは,第1に,契約当事者がセキュア設計について契約上どのような合意をしていたかです。セキュア設計について詳細に取り決めをしたり,特定のガイドラインに準拠してセキュア設計を行うべきことを契約書に盛り込んでおくことで,紛争化を防ぐことができます。

 

当事務所では,神戸・大阪・京都その他の地域からの,アプリ開発事業者の皆様のご相談に対応しております。アプリの脆弱性を巡ってユーザーとトラブルになってしまった場合の対応から,紛争を防ぐための契約の進め方のアドバイスまで,様々なご相談に対応しております。また,その他の開発契約紛争に関する対応や,アプリの利用規約・プライバシーポリシーの策定等に関するアドバイスにも対応しております。アプリに関する法律問題でお困りの際は,お気軽にご相談ください。

 

 

ー当事務所の「システム・アプリ関連紛争」法務サービスはこちらですー

ー当事務所の「情報セキュリティマネジメント」法務サービスはこちらですー

ー当事務所でご提供する法人向けサービスのご案内はこちらですー

―コラムの一覧はこちらです―

このコラムを書いた人

弁護士 石田優一
兵庫県弁護士会所属 68期 登録番号53402
情報処理安全確保支援士、応用情報技術者の資格を持つ若手弁護士。IT、IoT、営業秘密など、いつでもすぐに、最新の問題に対応するリーガルサービスを提供できるよう、5年先、10年先を読みながら、日々研鑽を積んでいる。
プロフィールはこちら

同じカテゴリのコラム記事

システム・アプリ関連紛争
アプリを企画する前に知っておきたい法律知識

みおの関連サービス