エンタープライズソフトウェア開発とOSS

エンタープライズ
ソフトウェア開発と
OSS
トレジャーデータ株式会社
ソフトウェアエンジニア
Hiroshi Nakamura @nahi

自己紹介
● エンタープライズシステム開発に21年。
その後企業向けWebサービス開発に3年。OSSに関わって18年。
● 分野
○ ネットワーク、情報セキュリティ
○ クラウド
○ ビッグデータ
● OSS
○ CRuby、JRubyコミッタ: 主にセキュリティ関係のコントリビュート
○ Rubyのhttpclient、ruby-openssl、logger等の開発
○ Ruby、Javaの各種ライブラリのコントリビュータ

https://github.com/blog/2270-meet-nahi-developer-and-ruby-contributor

ソフトウェア開発
OSS

OSS: オープンソースソフトウェア
● 「オープン」な利用ライセンス: https://choosealicense.com/ by GitHub
○ GitHubによる、オープンソースライセンスの選び方指南

自由に利用できる
一定の条件で再配布できる
https://choosealicense.com/

特許条項: 利用の心配が少ない

特許条項: 利用の心配が少ない
コピーレフト: 派生ソフトウェア
利用者はソースコードを
入手できなければならない

OSS: オープンソースソフトウェア
● 「オープン」な利用ライセンス: https://choosealicense.com/ by GitHub
○ もっと詳しく:
"オープンソースライセンスの基礎と実務" by 可知豊さん
https://www.slideshare.net/YutakaKachi/ss-8616029
● 汎用、ユーザを選ばない
○ 選ぶようなものはオープンにする意味がない
○ 具体的用途が直接には見えないながら、
抽象化→汎用を狙っていくのが醍醐味

"エンタープライズソフトウェア"のここでの定義
● エンタープライズシステム
○ 企業、事業体の情報システム全般
● エンタープライズソフトウェア
○ エンタープライズシステムの構成要素として開発されるソフトウェア
○ 特定のシステム専用（⇔ 汎用のプロダクトをカスタマイズ）
○ 企業、事業体のビジネスを直接支える、あるいはビジネスそのもの

ソフトウェア開発の分類
利用形態開発体制優先
内部利用開発主体、スポン
サーが別
（受託開発）
スコープ、品質、コスト、期日
外部サービス提供品質、コスト、期日
サービス開発サービス提供開発主体、スポン
サーが一致
スコープ、期日
ソフトウェア
プロダクト開発
プロダクト
ライセンス提供
スコープ、品質、期日
組込ソフトウェア開発品質、コスト、期日

エンタープライズソフトウェア開発とOSS
サーが別
（受託開発）
サーが一致
ソフトウェアプロダクト開発プロダクト
派生ソフトウェアの
再ライセンスが不要

ソフトウェア開発と
OSS
OSSの用途分類
メリットと注意点
OSSとの付き合い方

過去のOSS活用案件
● ネットワーク運用管理システム
● 金融機関向けアカウントアグリゲーションシステム
● 退職給付債務数理シミュレータ
● タイムスタンプサーバ
● 暗号演算専用ハードウェアを用いた、モバイル決済サービスの鍵管理システム
● ICカード発行工場のFAソフトウェア
● 企業および大学向け認証局 + PKIシステム
● 通信会社のモバイルアプリケーション配信鍵管理システム
● 公共機関向け情報配信、受信ソフトウェア
● 生命保険のWeb販売システムのクラウド移行
● Webビッディングシステムのクラウド移行
● データの収集・分析・連携を目的としたクラウド型データマネージメントサービス

OSS利用: 用途別
● 汎用ライブラリ: 言語拡張、ログ、DI、時間、データフォーマット、通信、セキュリティ
○ Apache commons、Guava、Logback、SL4J、Guice、Joda-Time、etc.
○ Jackson、MessagePack、HttpComponents、OpenSSL、curl、GnuPG、BouncyCastle、JSch、csv、soap4r、httpclient、ruby-openssl、
JRuby-OpenSSL、openpgp4u、pkcs1、pkcs12、Salesforce API clients
● 開発支援ツール: ビルド、ライブラリ依存管理、 SCM、エディタ、CI、BTS、ユニットテスト、静的コード管理、テ
スト用DB、負荷テストツール、テスト用サーバ、テスト用 Proxy
○ Maven、Gradle、RubyGems、Bundler、Subversion、git、Eclipse、IntelliJ、Jenkins、Bugzilla、Trac、JUnit、FindBugs、PMD、Cobertura、
JaCoCo、h2、SQLite、JMeter、Wireshark、WEBrick、SocketProxy
● ミドルウェア、インフラ : アプリサーバ、メッセージング、データベース、 OS、仮想化、実装言語
○ Tomcat、JBoss、Jetty、Netty、Spring、Hibernate、MyBatis、ServiceMix、OpenESB、ActiveMQ、Apache CXF、Velocity、Hazelcast、
Rails、Linux、Docker、OpenVPN、OpenSSH、Apache httpd、Nginx、Squid、OpenLDAP、MySQL、PostgreSQL、Redis、Java、Ruby
● 運用支援: 構成管理、モニタリング
○ Chef、Sensu、Fluentd、Tripwire、OSSEC、mod_security

OSSの
活用方法
● 開発におけるOSS利用
○ ライブラリ、開発支援ツール
○ システム連携
● ミドルウェア、インフラ、運用でのOSS利用
○ ベンダーロックインの回避
○ サポートの問題
● プロジェクトリスク管理のためのOSS利用
○ リスク回避
○ OSSのように開発する

開発におけるOSS利用 (1/2)
● ライブラリ: 再利用促進、生産性向上
● 開発支援ツール: 生産性向上
● 「汎用」→ 環境の差異の吸収
● システム連携での標準仕様の取り込み
○ データフォーマット、通信、セキュリティ
○ セキュリティの落とし穴に注意

開発におけるOSS利用 (2/2)
● ドキュメントを充実させる必要がある
○ 利用方法、追加開発サンプル
○ 設定方法、
○ モニタ方法、デバッグ方法
○ アップデートの定期モニタリング
● 対象OSSの見極め
○ ライセンス: 再配布が必要なソフトウェアの場合には、著作権に留意
○ 配布方法: リリース形態、頻度
○ プロジェクト状態の見極め
■ 開始時期、defaultブランチのcommit、issuesのactivity、PR数、fork数

(A) クライアント (内部サーバ向け)
(B) クライアント (外部サーバ向け)
(C) サーバ (内部クライアント向け)
(D) サーバ (外部クライアント向け)
(E) 認証
(F) サーバでの暗号化
(G) クライアントでの暗号化
システム連携セキュリティの7つのパターン
実装対象 / 外部システム

(E) 認証
(F) サーバでの暗号化
(G) クライアントでの暗号化
パターン別注意度
実装対象 / 外部システム
パターン通りに実装
落とし穴に注意
避ける

要件
● 通信の保護
● 固定のサーバへの接続のみ許可
注意点
➔ SSL設定: CBC, SSLv3.0, compression,
TLSv1.0, RC4, DHE1024, …
➔ 想定以外のサーバへの接続が
失敗することをテスト
ライブラリ
HttpComponents, httpclient, curl, OpenSSL, JSch
(A)
(A)

要件
● 通信の保護
● 特定のサーバへの接続のみ許可
注意点
➔ SSL設定
➔ サーバ証明書が失効されている場合
接続が失敗することをテスト
ライブラリ
HttpComponents, httpclient, curl, OpenSSL, JSch
(B)
(B)
(A)
(A)

SSL設定の確認
require 'httpclient'
client = HTTPClient.new
client.get('https://www.ruby-lang.org/en/').status
=begin
% ruby -d a1.rb
ok: "/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA"
ok: "/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3"
ok: "/C=US/ST=California/L=San Francisco/O=Fastly, Inc./CN=m.ssl.fastly.net"
Protocol version: TLSv1.2
Cipher: ["ECDHE-RSA-AES128-GCM-SHA256", "TLSv1/SSLv3", 128, 128]
=end

弱い暗号の場合に失敗することをテスト
client.ssl_config.ssl_version = :TLSv1_2
client.get('https://localhost:17443/').status
=begin
% ruby a3.rb
SSL_connect returned=1 errno=0 state=SSLv3 read server hello A: wrong version number
(OpenSSL::SSL::SSLError)
=end

テスト用WEBrick SSL server
require 'webrick/https'
require 'logger'
logger = Logger.new(STDERR)
server = WEBrick::HTTPServer.new(
BindAddress: "127.0.0.1",
Logger: logger,
Port: 17443,
DocumentRoot: '/dev/null',
SSLEnable: true,
SSLCACertificateFile: 'ca-chain.cert',
SSLCertificate: OpenSSL::X509::Certificate.new(
File.read('server.cert')),
SSLPrivateKey: OpenSSL::PKey::RSA.new(
File.read('server.key')),
)
server.ssl_context.ssl_version = :TLSv1
basic_auth = WEBrick::HTTPAuth::BasicAuth.new(
Logger: logger, Realm: 'auth',
UserDB: WEBrick::HTTPAuth::Htpasswd.new('htpasswd')
)
server.mount('/hello',
WEBrick::HTTPServlet::ProcHandler.new(
->(req, res) {
basic_auth.authenticate(req, res)
res['content-type'] = 'text/plain'
res.body = 'hello'
})
)
trap(:INT) do
server.shutdown
end
t = Thread.new {
Thread.current.abort_on_exception = true
server.start
}
while server.status != :Running
sleep 0.1
raise unless t.alive?
end
puts $$
t.join

想定以外のサーバへの接続が失敗することをテスト
client.get('https://m.global-ssl.fastly.net/en/').status
=begin
% ruby -d a2.rb
ok: "/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA"
ok: "/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3"
ok: "/C=US/ST=California/L=San Francisco/O=Fastly, Inc./CN=m.ssl.fastly.net"
Protocol version: TLSv1.2
Cipher: ["ECDHE-RSA-AES128-GCM-SHA256", "TLSv1/SSLv3", 128, 128]
Exception `OpenSSL::SSL::SSLError' - hostname "m.global-ssl.fastly.net" does not
match the server certificate
=end

サーバ証明書が失効されている場合
client.get('https://revoked.grc.com/').status
% ruby b2.rb # => 200
% jruby b2.rb # => 200
% jruby -J-Dcom.sun.net.ssl.checkRevocation=true b.rb
OpenSSL::SSL::SSLError:
sun.security.validator.ValidatorException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: Could not determine revocation status
失効確認方式
● JavaはCRL、OCSPに対応
● RubyはOCSP（ただし自分で書かないとダメ）
● ChromeはCRLSet、FirefoxはOCSP、IEはOCSP→CRL

要件
● 通信の保護
● 特定のクライアントのみ接続許可
注意点
➔ SSL設定
➔ サーバの鍵管理
➔ サーバ証明書の更新運用
➔ 想定外のクライアントからの接続を
遮断することをテスト
ミドルウェア: Jetty, JBoss, Tomcat
(C)
(B)
(B)
(A)
(A)

要件
● 通信の保護
注意点
➔ SSL設定
➔ サーバの鍵管理
➔ サーバ証明書の更新運用
➔ 想定外のクライアントからの接続を
遮断することをテスト
➔ 鍵漏洩からのリカバリ
インフラとして: Apache httpd, Nginx
(D)
(C)
(B)
(B)
(A)
(A)

要件
● クライアント認証
● 保護されていないネットワークでの
安全性
注意点
➔ 暗号アルゴリズムの選択
➔ 改ざん検知
➔ タイミングアタック
ライブラリ
Spring, Apache Oltu, Devise, OmniAuth,
rack-oauth2, doorkeeper
(E) 認証
(A)
(A)
(B)
(B)
(C)
(D)
(E)
(E)

要件
● 保存時のデータ暗号化
注意点
➔ 暗号化アルゴリズム
➔ 暗号鍵の管理:
保存、認証、監査、鍵更新
➔ 改ざん検出
➔ 処理性能
インフラ: dm-crypt
ライブラリを使って実装するのでなく、
専用プロダクトか、外部サービスを利用する
(F) サーバ / (G) クライアントでの暗号化
(A)
(A)
(B)
(B)
(C)
(D)
(F)
(G)
(E)
(E)
避ける

Hot OSS: Jackhammer
One Security vulnerability
assessment/management tool to solve
all the security team problems
https://github.com/olacabs/jackhammer

ミドルウェア、インフラ、運用でのOSS利用 (1/2)
● ベンダーロックインの回避
● 受託開発ではインフラ、運用部分が分離されている
○ インフラ、運用部分ではOSSを自由には使えない傾向があった
○ クラウド利用増加に伴い、テスト、デプロイ部分のOSSが充実
○ 同じ理由で、ログ収集、モニタ、分析の自動化も

ミドルウェア、インフラ、運用でのOSS利用 (2/2)
● サポートの問題
● コンポーネントを組み合わせることで、運用、管理は複雑化する
● メンテナンス人員を確保する？
● OSS開発元企業、または他のOSSサポート企業のサービスを利用する？
● プロダクトを利用する？
● サービスを利用する？

(参考) トレジャーデータでのSREと利用ツール
Datadog, CloudWatch, NewRelic,
Pingdom, Slack, Sentry
PagerDuty, Runbook in Confluence
JIRA, Confluence, Zoom, Gyazo, Treasure Data
CircleCI, Github, Chef
JIRA
Datadog, AWS Auto Scaling
"Site Reliability Engineering" Edited by Betsy Beyer, Chris
Jones, Jennifer Petoff and Niall Richard Murphy
https://landing.google.com/sre/book.html

エンタープライズソフトウェア開発とOSS
サーが別
（受託開発）
サーが一致
ソフトウェアプロダクト開発プロダクト
派生ソフトウェアの再
ライセンスが不要

プロジェクトリスク管理のためのOSS利用
● スコープ変動リスク: 開発後半で開発スコープが増える、変わる
○ 「システム要件定義」「基本設計」フェーズでモック開発
● 複雑さによる遅延リスク: ドメインの複雑さにより開発が遅延する
○ 開発初期段階で先行実装、後段でターゲット環境へ移植
● 環境制約による突然死リスク: プロダクトの制約により実現不可能とわかる
○ OSSならいざとなれば vs プロフェッショナルによるサポート
● 組織運営上の停滞リスク

プロジェクトリスク管理のためのOSS利用
● スコープ変動リスク: 開発後半で開発スコープが増える、変わる
○ 「システム要件定義」「基本設計」フェーズでモック開発
● 複雑さによる遅延リスク: ドメインの複雑さにより開発が遅延する
○ 開発初期段階で先行実装、後段でターゲット環境へ移植
● 環境制約による突然死リスク: プロダクトの制約により実現不可能とわかる
○ OSSならいざとなれば vs プロフェッショナルによるサポート
● 組織運営上の停滞リスク: コミュニケーション不全により停滞する

OSSのように
開発することの
メリット
コミュニケーションをオープンにする
● 誰でも学べる
● 誰でも開発、レビューに参加できる
● タイムゾーンを超える
課題のトラッキングと自然な資産化
素早いローンチ: 短いトレーニング期間
対価として、オープンにするためのコストは大変
高い
● 誰でも確認できるテストを書く
● 誰でも理解できるドキュメントを書く

OSSのように
開発することの
メリット
コミュニケーションをオープンにする
● 誰でも学べる
● 誰でも開発、レビューに参加できる
● タイムゾーンを超える
課題のトラッキングと自然な資産化
素早いローンチ: 短いトレーニング期間
対価として、オープンにするためのコストがかか
る
● 誰でも確認できるテストを書く
● 誰でも理解できるドキュメントを書く

まとめ
● OSSライセンス3タイプ
● エンタープライズソフトウェア: 受託開発
● OSSの用途分類
● 開発におけるOSS利用
● システム連携ライブラリの落とし穴
● ミドルウェア、インフラ、運用でのOSS利用
● プロジェクトリスク管理のためのOSS利用
● OSSのように開発することのメリット

エンタープライズソフトウェア開発とOSS

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to エンタープライズソフトウェア開発とOSS

Similar to エンタープライズソフトウェア開発とOSS (20)

More from Hiroshi Nakamura

More from Hiroshi Nakamura (10)

エンタープライズソフトウェア開発とOSS